Re: Column correlation drifts, index ignored again

From: John Siracusa <siracusa(at)mindspring(dot)com>
To: Postgres Performance <pgsql-performance(at)postgresql(dot)org>
Subject: Re: Column correlation drifts, index ignored again
Date: 2004-02-22 22:34:47
Message-ID: BC5E98B7.2DCB2%siracusa@mindspring.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-performance

On 2/22/04 5:06 PM, Tom Lane wrote:
> John Siracusa <siracusa(at)mindspring(dot)com> writes:
>> I want to do something that will convince Postgres that using the date
>> index is, by far, the best plan when running my queries, even when the
>> date column correlation stat drops well below 1.0.
>
> Have you tried experimenting with random_page_cost? Seems like your
> results suggest that you need to lower it.

I don't want to do anything that "universal" if I can help it, because I
don't want to adversely affect any other queries that the planner currently
aces.

I'm guessing that the reason using the date index is always so much faster
is that doing so only reads the rows in the date range (say, 1,000 of them)
instead of reading every single row in the table (1,000,000) as in a seqscan
plan.

I think the key is to get the planner to correctly ballpark the number of
rows in the date range. If it does, I can't imagine it ever deciding to
read 1,000,000 rows instead of 1,000 with any sane "cost" setting. I'm
assuming the defaults are sane :)

-John

In response to

Responses

Browse pgsql-performance by date

  From Date Subject
Next Message Tom Lane 2004-02-22 23:30:11 Re: General performance questions about postgres on Apple
Previous Message Tom Lane 2004-02-22 22:06:58 Re: Column correlation drifts, index ignored again