From: | Ken Geis <kgeis(at)speakeasy(dot)org> |
---|---|
To: | Bruno Wolff III <bruno(at)wolff(dot)to> |
Cc: | pgsql-performance(at)postgresql(dot)org |
Subject: | Re: bad estimates |
Date: | 2003-08-30 07:38:13 |
Message-ID: | 3F505465.6010504@speakeasy.org |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-performance |
Bruno Wolff III wrote:
> I haven't come up with any great ideas for this one. It might be interesting
> to compare the explain analyze output from the distinct on query with
> and without seqscans enabled.
After digging through planner code, I found that bumping up the sort_mem
will make the planner prefer a full table scan and hashed aggregation.
The sort memory is where the hash table is stored. In the end, the
query runs in 4.5 minutes, which is reasonable.
I had planned to try Manfred's index correlation patch to see if it
would give better estimates for an index scan. The index scan method
took maybe 6.5x as long, but the estimate was that it would take 1400x
as long. I think instead of trying out his patch I might actually work
on my application!
Ken
From | Date | Subject | |
---|---|---|---|
Next Message | Jeff | 2003-08-30 13:08:51 | Re: Selecting random rows efficiently |
Previous Message | Ron Johnson | 2003-08-30 05:21:17 | Re: Hardware recommendations to scale to silly load |