Re: Optimization with dates

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Jason Earl <jason(dot)earl(at)simplot(dot)com>
Cc: Jean-Christophe Boggio <cat(at)thefreecat(dot)org>, pgsql-sql(at)postgresql(dot)org
Subject: Re: Optimization with dates
Date: 2001-11-14 02:20:34
Message-ID: 4513.1005704434@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-sql

Jason Earl <jason(dot)earl(at)simplot(dot)com> writes:
> I have a similar table (~16M rows) with an indexed timestamp, and have
> had similar problems. I have found that even when I am using a
> constant timestamp like in this query.

> SELECT * FROM caseweights1 WHERE dt > '2001-11-01';

> I start getting sequential scans with 7.1.3 long before they are
> faster than index based queries.

Just out of curiosity, do the indexed timestamps correlate closely to
the physical order of the table? I'd expect that to happen if you
are timestamping records by insertion time and there are few or no
updates.

7.1 and before assume that the index order is random with respect to
the physical order, which is a good conservative assumption ... but it
results in drastically overestimating the cost of an indexscan when
strong correlation exists. 7.2 keeps some statistics about ordering
correlation, and may perhaps do better with this sort of situation.
(I have no doubt that its estimates will need further tweaking, but
at least the effect is somewhat accounted for now.)

regards, tom lane

In response to

Responses

Browse pgsql-sql by date

  From Date Subject
Next Message Llew Goodstadt 2001-11-14 02:43:50 Re: how do I update or insert efficently in postgres
Previous Message Jason Earl 2001-11-14 00:49:45 Re: Optimization with dates