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

In response to

Browse pgsql-performance by date

  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