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. Martin "PostgreSQL" <martin@xxxxxxxxxxx> wrote in message news:dkko49$1v06$1@xxxxxxxxxxxxxxx > 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
