Re: Slow Postgresql server
От
Guido Neitzer
Тема
Re: Slow Postgresql server
Дата
Msg-id
0914C05F-BA1B-4A6C-A1B1-52256BC851A4@event-s.net
Ответ на
Список
Дерево обсуждения
Slow Postgresql server Jason Lustig <lustig@brandeis.edu>
Re: Slow Postgresql server Dennis Bjorklund <db@zigo.dhs.org>
Re: Slow Postgresql server Ron <rjpeace@earthlink.net>
Re: Slow Postgresql server Guido Neitzer <lists@event-s.net>
Re: Slow Postgresql server Ron <rjpeace@earthlink.net>
Re: Slow Postgresql server Guido Neitzer <lists@event-s.net>
Re: Slow Postgresql server Scott Marlowe <smarlowe@g2switchworks.com>
Re: Slow Postgresql server Jeff Frost <jeff@frostconsultingllc.com>
Re: Slow Postgresql server Carlos Moreno <moreno_pg@mochima.com>
Strangely Variable Query Performance Steve <cheetah@tanabi.org>
Re: Strangely Variable Query Performance Scott Marlowe <smarlowe@g2switchworks.com>
Re: Strangely Variable Query Performance Steve <cheetah@tanabi.org>
Re: Strangely Variable Query Performance Scott Marlowe <smarlowe@g2switchworks.com>
Re: Strangely Variable Query Performance Tom Lane <tgl@sss.pgh.pa.us>
Re: Strangely Variable Query Performance Steve <cheetah@tanabi.org>
Re: Strangely Variable Query Performance Tom Lane <tgl@sss.pgh.pa.us>
Re: Strangely Variable Query Performance Steve <cheetah@tanabi.org>
Re: Strangely Variable Query Performance Tom Lane <tgl@sss.pgh.pa.us>
Re: Strangely Variable Query Performance Steve <cheetah@tanabi.org>
Re: Strangely Variable Query Performance Tom Lane <tgl@sss.pgh.pa.us>
Re: Strangely Variable Query Performance Steve <cheetah@tanabi.org>
Re: Strangely Variable Query Performance Tom Lane <tgl@sss.pgh.pa.us>
Re: Strangely Variable Query Performance Steve <cheetah@tanabi.org>
Re: Strangely Variable Query Performance Tom Lane <tgl@sss.pgh.pa.us>
Re: Strangely Variable Query Performance Tom Lane <tgl@sss.pgh.pa.us>
Re: Strangely Variable Query Performance Steve <cheetah@tanabi.org>
Re: Strangely Variable Query Performance Tom Lane <tgl@sss.pgh.pa.us>
Fwd: Strangely Variable Query Performance "Robins Tharakan" <robins@pobox.com>
Fwd: Strangely Variable Query Performance Robins <tharakan@gmail.com>
Re: Fwd: Strangely Variable Query Performance Tom Lane <tgl@sss.pgh.pa.us>
choose_bitmap_and again (was Re: Strangely Variable Query Performance) Tom Lane <tgl@sss.pgh.pa.us>
Re: [HACKERS] choose_bitmap_and again (was Re: Strangely Variable Query Performance) Alvaro Herrera <alvherre@commandprompt.com>
Re: [HACKERS] choose_bitmap_and again (was Re: Strangely Variable Query Performance) Tom Lane <tgl@sss.pgh.pa.us>
Re: [HACKERS] choose_bitmap_and again (was Re: Strangely Variable Query Performance) Tom Lane <tgl@sss.pgh.pa.us>
Re: Strangely Variable Query Performance Steve <cheetah@tanabi.org>
Re: Strangely Variable Query Performance Steve <cheetah@tanabi.org>
Re: Strangely Variable Query Performance Tom Lane <tgl@sss.pgh.pa.us>
Re: Strangely Variable Query Performance Steve <cheetah@tanabi.org>
Re: Strangely Variable Query Performance Tom Lane <tgl@sss.pgh.pa.us>
Re: Strangely Variable Query Performance Steve <cheetah@tanabi.org>
Re: Strangely Variable Query Performance Tom Lane <tgl@sss.pgh.pa.us>
Re: Strangely Variable Query Performance Steve <cheetah@tanabi.org>
Re: Slow Postgresql server Jeff Frost <jeff@frostconsultingllc.com>
On 12.04.2007, at 08:59, Ron wrote: > 1= Unless I missed something, the OP described pg being used as a > backend DB for a webserver. Yep. > I know the typical IO demands of that scenario better than I > sometimes want to. > :-( Yep. Same here. ;-) > 2= 1GB of RAM + effectively 1 160GB HD = p*ss poor DB IO support. Absolutely right. Depending a little bit on the DB and WebSite layout and on the actual requirements, but yes - it's not really a kick-ass machine ... > Completely agree that at some point the queries need to be examined > (ditto the table schema, etc), but this system is starting off in a > Bad Place for its stated purpose IME. > Some minimum stuff is obvious even w/o spending time looking at > anything beyond the HW config. Depends. As I said - if the whole DB fits into the remaining space, and a lot of website backend DBs do, it might just work out. But this seems not to be the case - either the site is chewing on seq scans all the time which will cause I/O or it is bound by the lack of memory and swaps the whole time ... He has to find out. cug
В списке pgsql-performance по дате отправления