[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

RE: repository GUIDs

From: Bill Tutt <rassilon_at_lyra.org>
Date: 2002-12-12 21:43:11 CET

It feels right, but sometimes it's necessary to cluster an index on an
Alternative Key or indeed even on a non-unique column rather than the
Primary Key for various reasons. The reasons in this case are space
optimization related. Our funky base-whatever IDs are much shorter than
the number of bytes a GUID has. Monotonically increasing integers also
use a B+-tree index more efficiently.

The new table under discussion is an example of wanting to index a table
by an Alternative Key, and here's an example of indexing a table by a
non-unique key:

Searching for Businesses in a Yellow Pages system:
There are several million businesses in the US. It turns out the most
efficient business search queries result out of indexing the Business
table by (ZipCode, BusinessID) as opposed to just by BusinessID.

Both of these approaches are slightly counter intuitive, but they do
deliver concrete query performance results.


Do you want a dangerous fugitive staying in your flat?
Well, don't upset him and he'll be a nice fugitive staying in your flat.
> -----Original Message-----
> From: Karl Fogel [mailto:kfogel@newton.ch.collab.net]
> Sent: Thursday, December 12, 2002 11:36 AM
> To: mark benedetto king
> Cc: Branko ?ibej; Bill Tutt; dev@subversion.tigris.org
> Subject: Re: repository GUIDs
> mark benedetto king <bking@answerfriend.com> writes:
> > Performance considerations aside, the table would not be
> > just another layer of indirection.  Here's a proposed table:
> Thanks for the extra context, that helps.
> But, still, it would be simpler if the key were the GUID, and the rest
> of the information were the value, no?  The whole point of the GUID is
> to be a "primary key" of sorts for that repository, in the Grand
> Universal Database That Is The Internet.  It just feels right to use
> the PK as the PK, if I may phrase it prejudicially :-).
> -K
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Thu Dec 12 21:43:47 2002

This is an archived mail posted to the Subversion Dev mailing list.