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 21:58:30 |
Message-ID: | BC5E9036.2DCA2%siracusa@mindspring.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-performance |
On 2/22/04 2:05 PM, Josh Berkus wrote:
> On Saturday 21 February 2004 16:18, John Siracusa wrote:
>> Next, thanks to my earlier thread, I clustered the table on the date
>> column and then "SET STATISTICS" on the date column to be 100. That
>> did the trick, and I stopped explicitly disabling seqscan.
>
> 100? Are you sure you don't mean some other number? 100 is not very high
> for problem analyze issues. You might try 500.
IIRC, 100 was the number suggested in the earlier thread. I did set it to
500 yesterday, I believe. We'll see how that goes.
> Generally when I have a problem query I raise stats to something like 1000 and
> drop it down until the problem behaviour starts re-appearing.
Since this problem takes a long time to appear (months), that cycle could
take a long time... :)
>> date_trunc('day', date) AS date
>
> Have you tried putting an index on date_trunc('day', date) and querying on
> that instead of using this:
>
>> date BETWEEN '2004-02-01 00:00:00' AND '2004-02-28 23:59:59'
No, but then I'd just have a different index to persuade the planner to use
:) Not every query does date_trunc() stuff, but they all do date ranges,
often at a granularity of seconds.
-John
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2004-02-22 22:06:58 | Re: Column correlation drifts, index ignored again |
Previous Message | Josh Berkus | 2004-02-22 19:05:57 | Re: Column correlation drifts, index ignored again |