Re: postgresql +AMD64 +big address spaces - does it work?
От | Chris Browne |
---|---|
Тема | Re: postgresql +AMD64 +big address spaces - does it work? |
Дата | |
Msg-id | 607jthndfp.fsf@dev6.int.libertyrms.info обсуждение исходный текст |
Ответ на | Re: postgresql +AMD64 +big address spaces - does it work? ("Glen Parker" <glenebob@nwlink.com>) |
Ответы |
Re: postgresql +AMD64 +big address spaces - does it work?
|
Список | 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 по дате отправления: