Re: postgresql +AMD64 +big address spaces - does it work? - Mailing list pgsql-general

From Chris Browne
Subject Re: postgresql +AMD64 +big address spaces - does it work?
Date
Msg-id 607jthndfp.fsf@dev6.int.libertyrms.info
Whole thread Raw
In response to Re: postgresql +AMD64 +big address spaces - does it work?  ("Glen Parker" <glenebob@nwlink.com>)
Responses Re: postgresql +AMD64 +big address spaces - does it work?  (Christopher Petrilli <petrilli@gmail.com>)
List pgsql-general
"Andy B" <abhousehuntRE-M--O--V-E@blueyonder.co.uk> writes:
>> I get the feeling that, that regardless 64bit support or not, that the
>> *concept* of a database which just happens to all easily fit within RAM
>> isn't one that gets the thumbs down...
>
> Oops, I meant to say '*is*' one that gets the thumbs down...

No, to the contrary, having all the data fit easily within RAM is
quite desirable.  One of my coworkers is investigating the
entertaining possibility of hooking up SSDs to some of our systems to
entirely eliminate disk I/O for WAL.  (The fun part then is to see
what more can be done with another 3GB of space on the SSD that can
eliminate a bunch more I/O  :-)...)

The thing that gets "thumbs down" is the notion of trying to _force_
that to take place by maximizing shared buffer size, based on the
assumption that such a strategy is optimal for the purpose.

By all means, get a big AMD box with plenty of RAM; just _don't_
assume that tweaking shared buffers is the "majick trick" that will
make it all work 50x faster.
--
output = reverse("moc.enworbbc" "@" "enworbbc")
http://cbbrowne.com/info/internet.html
"A lot  of people come to  this newsgroup and  do nothing but complain
about Lisp.   I think maybe they  are such heavy complainers that they
think they read comp.lain.lisp." -- Erik Naggum

pgsql-general by date:

Previous
From: Stephan Szabo
Date:
Subject: Re: Interpreting query plan
Next
From: Bruno Wolff III
Date:
Subject: Re: backup using cron