My most humble apologies to the pg development team (pg_lets?).

I took Greg Stark's advice and set:

shared_buffers = 10000  # was 50000
work_mem = 1048576    # 1Gb - was 16384

Also, I noticed that the EXPLAIN ANALYZE consistently thought reads would 
take longer than they actually did, so I decreased random_page_cost down to 
1 (the server has a SATA Raid at level 10).

Queries that previously seemed to stall out are still a little slow but 
nothing like before.  And I'm seeing a more normal balance of CPU and disk 
i/o while a query is running instead of the high-cpu-low-disk-read situation 
I was seeing before.  Concurrency is way up.

I tried a couple of interim sizes for work_mem and so far, the larger the 
better (the server has 16Gb).  I'll test a little larger size this evening 
and see what it does.  Yes, I've read the warning that this is per process.

Kudos to you Greg, thanks Luke for your comment (though it seems to disagree 
with my experience).  Also to Dennis, there were not drastic changes in the 
plan between 8.0 and 8.1, it was just the actual execution times.


"PostgreSQL" <[EMAIL PROTECTED]> wrote in message 
> SELECT v_barcode, count(v_barcode) FROM lead GROUP BY v_barcode HAVING 
> count(*) > 1;
> This is a pretty good example of the place where 8.1 seems to be quite 
> broken.

---------------------------(end of broadcast)---------------------------
TIP 6: explain analyze is your friend

Reply via email to