[Lazarus] Postgres database again...

[Michael Van Canneyt]

On Wed, 28 May 2008, Bogusław Brandys wrote:

> 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.

I know this very well, but then the queries run unacceptably slow.
We are forced to increase the number of pages kept in memory, sometimes
almost to the complete database size.

Michael.