From: | John Siracusa <siracusa(at)mindspring(dot)com> |
---|---|
To: | Postgres Performance <pgsql-performance(at)postgresql(dot)org> |
Subject: | Re: Use my (date) index, darn it! |
Date: | 2004-01-05 16:19:04 |
Message-ID: | BC1EF8A8.712CE%siracusa@mindspring.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-performance |
On 1/5/04 1:55 AM, Tom Lane wrote:
> John Siracusa <siracusa(at)mindspring(dot)com> writes:
>> Obviously the planner is making some bad choices here.
>
> A fair conclusion ...
>
>> I know that it is trying to avoid random seeks or other scary things
>> implied by a "correlation" statistic that is not close to 1 or -1, but
>> it is massively overestimating the hit caused by those seeks and
>> seemingly not taking into account the size of the table!
>
> You haven't given any evidence to support these conclusions, though.
Well here's what I was basing that theory on: before clustering, the
correlation for the date column was around 0.3. After clustering, it was 1,
and the index was always used. Does clustering change any other statistics
other that correlation? I ran analyze immediately before and after the
cluster operation.
> Could we see some table schemas, EXPLAIN ANALYZE output, and relevant
> pg_stats entries for the various cases?
Well, the table is clustered now, so I can't reproduce the situation. Is
there any way to "uncluster" a table? Should I just cluster it on a
different column?
-John
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2004-01-05 16:29:50 | Re: Use my (date) index, darn it! |
Previous Message | Tom Lane | 2004-01-05 15:22:32 | Re: optimizing Postgres queries |