Re: PERFORMANCE meeting summary & next meeting topic!

From: "David E(dot) Wheeler" <david(at)kineticode(dot)com>
To: "Roth, Gabrielle" <gabrielle(dot)roth(at)xo(dot)com>
Cc: <pdxpug(at)postgresql(dot)org>
Subject: Re: PERFORMANCE meeting summary & next meeting topic!
Date: 2006-09-20 22:04:31
Message-ID: C2080B52-D287-435C-88A9-DC1EEB04869F@kineticode.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pdxpug

On Sep 20, 2006, at 14:40, Roth, Gabrielle wrote:

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

Oh, right. Duh. That's almost always the first thing I do when I have
query problems, actually.

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

Good analyzing the issue! 40ms must be quite respectable after
2800ms, eh?

>> Thanks for a fun meeting, all!
> \e! \e! I used it today!

:-)

Best,

David

In response to

Browse pdxpug by date

  From Date Subject
Next Message Mark Wong 2006-09-25 21:56:32 on-disk bitmap indexes
Previous Message Roth, Gabrielle 2006-09-20 21:40:00 Re: PERFORMANCE meeting summary & next meeting topic!