[Lazarus] Postgres database again...

[Bogusław Brandys]

Michael Van Canneyt wrote:
> 
> On Tue, 27 May 2008, Graeme Geldenhuys wrote:
> 
>> Michael Van Canneyt wrote:
>>>> Cons:
>>>>   * Yes it's longer than an Integer type and uses more space, but with 
>>>> today's hard drive sizes that is totally irrelevant.
>>> The size on disk is not relevant, but the size in memory is. Speed is an
>>> issue, and the smaller the data is, the more can be kept in memory, and the
>>> faster the engine can traverse it when doing queries.
>>>
>>> It's the very reason why I don't use GUIDs as primary keys.
>>>
>>> If you have a busy server, 8 CPU's, lots of memory, but 500 simultaneous
>>> connections, such seemingly unimportant details all of a sudden do become 
>>> important.
>> Memory is cheap too!  :)
> 
> Do you know a server that can handle memory to keep a 2Gb database 500 times
> in memory ? And the database is expected to grow in size considerably.
> I don't even mention backup and restore times :(
> 
> I understand and very much appreciate the technical advantages of a GUID, 
> but the database size at a certain point simply dwarfs the importance of 
> all other factors... 
> 
> I'm eagerly awaiting the Firebird 2.5 release, which should have proper
> SMP support in the superserver architecture. That should make it possible
> to keep the database in memory only once, instead of a copy per connection
> as in classical server. And then size suddenly will be much less of an
> issue. 
> 
> But until then: size matters - to paraphrase 90% of spam in my mailbox ;-)
> 
> Michael.

I think you are wrong about Firebird.It doesn't keep database in memory 
, only page buffers which is adjustable and should be really set to 
lower values then for Firebird Superserver.

GUID's are bad however because of indexing. They should be reversed or 
something , I don't know exactly to limit time required to search over 
indexed GUID field in Firebird database.



Regards
Boguslaw