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
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 |