Am Montag, 7. November 2005 18:22 schrieb PostgreSQL:
> My most humble apologies to the pg development team (pg_lets?).
>
> I took Greg Stark's advice and set:
>
> shared_buffers = 1 # was 5
> work_mem = 1048576# 1Gb - was 16384
>
> Also, I noticed that the EXPLAIN ANALYZE consistently
My most humble apologies to the pg development team (pg_lets?).
I took Greg Stark's advice and set:
shared_buffers = 1 # was 5
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 decr
On Sun, 6 Nov 2005, PostgreSQL wrote:
> SELECT v_barcode, count(v_barcode) FROM lead GROUP BY v_barcode HAVING
> count(*) > 1;
>
> This is a dual Opteron box with 16 Gb memory and a 3ware SATA raid
> runing 64bit SUSE. Something seems badly wrong.
>
> GroupAggregate (cost=9899282.83..10285434
SQL <[EMAIL PROTECTED]>
CC: pgsql-performance@postgresql.org
Sent: Sun Nov 06 14:24:00 2005
Subject: Re: [PERFORM] 8.1 iss
"PostgreSQL" <[EMAIL PROTECTED]> writes:
...
> As I post this, the query is approaching an hour of run time. I've listed
> an explain of the qu
"PostgreSQL" <[EMAIL PROTECTED]> writes:
...
> As I post this, the query is approaching an hour of run time. I've listed
> an explain of the query and my non-default conf parameters below. Please
> advise on anything I should change or try, or on any information I can
> provide that could he
"PostgreSQL" <[EMAIL PROTECTED]> writes:
> This is a pretty good example of the place where 8.1 seems to be quite
> broken.
That's a bit of a large claim on the basis of one data point.
Did you remember to re-ANALYZE after loading the table into the
new database?
regards,
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. I understand that this query will want to do a full table scan
(even through v_barcode is indexed). And the table is largish, at
