What does
SET enable_seqscan = false;
EXPLAIN ANALYZE SELECT * FROM ...
get you? Is it faster?
BTW, I suspect this behavior is because the estimates for the cost of an
index scan don't give an appropriate weight to the correlation of the
index. The 'sort and index' thread on this list from a
[Jim C. Nasby - Thu at 01:04:53PM -0500]
What does
SET enable_seqscan = false;
EXPLAIN ANALYZE SELECT * FROM ...
get you? Is it faster?
I was experimenting with this some weeks ago, by now our database server has
quite low load numbers and I haven't gotten any complaints about anything
On Mon, May 30, 2005 at 05:19:51PM +0800, Tobias Brox wrote:
We have a production database with transaction-style data, in most of the
tables we have a timestamp attribute created telling the creation time of
the table row. Naturally, this attribute is always increasing.
The message subject
[Michael Fuhr - Mon at 07:54:29AM -0600]
The message subject is timestamp indexing but you don't mention
whether you have an index on the timestamp column. Do you?
Yes. Sorry for not beeing explicit on that.
Could you post an example query and its EXPLAIN ANALYZE output? If
the query uses
Tobias Brox [EMAIL PROTECTED] writes:
What version of PostgreSQL are you using?
Also answered in my follow-up - not yet pg8 :)
Your followup hasn't shown up here yet, but if the query is written like
WHERE timestampcol = now() - interval 'something'
then the pre-8.0 planner is not
[Tom Lane - Mon at 01:57:54PM -0400]
Your followup hasn't shown up here yet,
I'll check up on that and resend it.
but if the query is written like
WHERE timestampcol = now() - interval 'something'
then the pre-8.0 planner is not capable of making a good estimate of the
selectivity of
[Tobias Brox - Tue at 10:06:25AM +0800]
[Tom Lane - Mon at 01:57:54PM -0400]
Your followup hasn't shown up here yet,
I'll check up on that and resend it.
Hrm ... messed-up mail configuration I suppose. Here we go:
Paul McGarry unintentionally sent a request for more details off the list,
