Subject | Re: [ib-support] Re: Generating UniqueID [2] |
---|---|
Author | Ann W. Harrison |
Post date | 2001-11-10T22:21:36Z |
I wrote:
you'll tend to have compressed key lengths > 10, meaning that
the index will be about twice as wide.
simple counter (I think) that avoids problems of simultaneous
actions.
Regards,
Ann
www.ibphoenix.com
We have answers.
> >The GUID algorithm that I am familiar with changes the first byteAt 01:40 AM 11/10/2001 +0000, zifnabbe@... wrote:
> >for each new id, greatly reducing the effect of prefix compression.
> >Less compression -> longer keys -> fewer keys per page -> deeper
> >indexes -> worse performance.
>How can this performance be compared over a NUMERIC(18,0)?If in fact the first byte of the GUID changes most frequently,
you'll tend to have compressed key lengths > 10, meaning that
the index will be about twice as wide.
>Is it a drastic performance hit? Or can we assume that a benefit of a GUIDThat's certainly application specific.
>overrules the performance hit?
>But thinking further... If we create the GUID on the interbaseActually the GUID is more complicated than that and includes a
>server, then the only difference in the number is the time value.
simple counter (I think) that avoids problems of simultaneous
actions.
Regards,
Ann
www.ibphoenix.com
We have answers.