[Lazarus] Postgres database again...

[Bogusław Brandys]

Graeme Geldenhuys wrote:
> 2008/5/28 Bogusław Brandys <brandys at o2.pl>:
> 
> Thanks for the information.
> 
> 
>> "As you are transforming your GUID, try to keep the least volatile bytes at
>> the front and the most volatile at the end.  Firebird uses prefix
>> compression in its indexes and the saving in space on the index pages
>> absolutely will improve performance on all but the most trivial data sets.
>>
>> Ann"
> 
> Sorry, but this might sound dumb... What what exactly does this mean?
> Am I supposed to change the GUID somehow?
> 
> 
> 
> Regards,
>  - Graeme -
> 

Sorry,I don't know details either , just found  a bunch of discussion 
from old times...

"Luke,

if you really have to use GUID's, than one possibillity would be to
reverse the GUID, so that the
equal parts are not in front of the GUID-string. This speeds up index
searches.
If you do not have to use GUID's, use Generators.

Uwe"


"straight GUIDs (e.g. generated by Delphi written application) has their
significant part at the end which does not provide for optimal indexing. Use
of the UDF generating UUID (reverse GUID) is said to improve performance
over the PK dramatically.
As for fieldtype - there are some suggestions here on the gourp as to what
datatype to use.
Here I quote a recent discussion with some pros and cons:

(read from the bottom perhaps)
It is a valid point, but you need to do the math for the specific problem
being resolved to decide how valid.  With small index column sizes you need
much more detail than I have at my fingertips to compute a real value, but
let's say that you go to a 4 byte integer key.  You lose 34 bytes from the
index entry footprint, giving 50-34=16 bytes per entry plus some overheads.
On an 8k page this gives you roughly 500 entries.  At two levels in the B+
tree you address 250,000 rows.  At three levels you can address 125,000,000
rows.

If you table space is expected to grow to 4,000,000 rows then you still have
to expand the index to three levels, but you can go a lot further on three
levels than you can with a larger key.

GUID's are ideal for distributed systems, but are not the most efficient way
of handling centralized systems.

It's a matter of the favorite hammer.  Sometimes you need a paintbrush, and
a hammer just won't do.   You can't let your (or my) favorite solution be
the only solution you know because it is not appropriate for every
situation."

> _______________________________________________
> fpGUI - a cross-platform Free Pascal GUI toolkit
> http://opensoft.homeip.net/fpgui/
> 
> _______________________________________________
> Lazarus mailing list
> Lazarus at lazarus.freepascal.org
> http://www.lazarus.freepascal.org/mailman/listinfo/lazarus
>