Re: PERFORMANCE meeting summary & next meeting topic!

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

In response to

Responses

Browse pdxpug by date

  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!