Re: seqscan strikes again

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: "Jim C(dot) Nasby" <decibel(at)decibel(dot)org>
Cc: pgsql-performance(at)postgresql(dot)org
Subject: Re: seqscan strikes again
Date: 2004-11-09 23:24:32
Message-ID: 6304.1100042672@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-performance

"Jim C. Nasby" <decibel(at)decibel(dot)org> writes:
> I'm wondering if there's any way I can tweak things so that the estimate
> for the query is more accurate (I have run analyze):

> -> Index Scan using alert__tick_tsz on alert (cost=0.00..2498.49 rows=7119 width=28) (actual time=0.006..0.030 rows=12 loops=1413)
> Index Cond: (("outer".prev_end_time < ms_t(alert.tick)) AND ("outer".end_time >= ms_t(alert.tick)))

Can you alter the data representation? 7.4 doesn't have any stats about
functional indexes and so it's not likely to come up with a good number
about the selectivity of the index on ms_t(tick). It might be worth
materializing that value as a plain column and indexing the column.

(This being a join, I'm not sure it would help any, but it seems worth
trying.)

regards, tom lane

In response to

Browse pgsql-performance by date

  From Date Subject
Next Message Cao Duy 2004-11-10 09:35:50 simple select-statement takes more than 25 sec
Previous Message Joshua D. Drake 2004-11-09 23:14:36 Re: seqscan strikes again