From: | "Roth, Gabrielle" <gabrielle(dot)roth(at)xo(dot)com> |
---|---|
To: | <pdxpug(at)postgresql(dot)org> |
Subject: | Re: PERFORMANCE meeting summary & next meeting topic! |
Date: | 2006-09-20 21:40:00 |
Message-ID: | E2383CA82A645A45B72D523F5A29311A032BC89C@UTSANDMAIL02.mail.inthosts.net |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pdxpug |
Mr Wheeler wrote:
> Actually, I think that the consensus was that she should try
> increasing the sort_mem on the 7.4 database to see if that
> helps. But upgrading is a no-brainer, too. :-)
Based on my tests today, upgrading is going to be the solution for sure.
On 8.1, the runtime for the problem query is ~5msec.
In the meantime, while I wait to schedule the prod upgrade *cough*, I
tried two things:
1. VACUUM ANALYZE. Duh. This should have been the first thing I
checked. (Forgot to put this test db in the maintenance queue. :$
*slaps self*) This improved things significantly (~2800 msec runtime as
calculated by the planner down to ~50msec. Yay.) This would be why my
indexes weren't being used.
2. I tried doubling sort_mem on my production machine to 2048K. It
made a noticable difference (we're down to ~40msec now, yee-haw). This
had no [visible] detrimental effect on the machine, and since I only
have 14 users & most of my queries are pretty straightforward, I figured
I could keep pushing it. However, further increases of sort_mem didn't
make any difference (I tried up to 16384), so I left it at 2048.
> Thanks for a fun meeting, all!
\e! \e! I used it today!
- gabrielle -
"5 out of 4 people have a problem with math."
From | Date | Subject | |
---|---|---|---|
Next Message | David E. Wheeler | 2006-09-20 22:04:31 | Re: PERFORMANCE meeting summary & next meeting topic! |
Previous Message | Selena Deckelmann | 2006-09-20 17:54:26 | Re: PERFORMANCE meeting summary & next meeting topic! |