Ray Ontko <[EMAIL PROTECTED]> writes:
> BTW, Are you sure that you need to do the "distinct"?
That's a good question to ask.
> If you do,
> then you might try putting the order_date column first in the
> select list. The distinct is requiring that all the rows be sorted
> so that they can be un
Please use "explain analyze" instead of just "explain"; the additional
information is very helpful to see where the query is actually spending
time.
Have you considered clustering on the order_date index? We have
seen dramatic improvements in situations where the table is
physically ordered by t
> Unsurprising. An inequality condition may require fetching many rows
> (the planner is estimating 336289 rows here...) and so an indexscan is
> not necessarily quicker. Have you compared actual runtimes with
> enable_seqscan on and off?
I did run with enable_seqscan off. You are right, the pl
"A.Bhuvaneswaran" <[EMAIL PROTECTED]> writes:
> I have a table and an index on it. The index is used when i use '=3D'
> operator for the indexed field in the where condition. But the index is
> not used when i use '>=3D' operator for the same field.
Unsurprising. An inequality condition may requi
