On Thu, Oct 1, 2009 at 10:21 PM, Tim Uckun wrote:
>
> Interesting. I would have thought the order of the fields would not
> matter. I don't have to rewrite the query do I?
>
>
No. For multi-column indices, however, postgres can, starting at the
leftmost in the index, use as many columns as match
>
> If you try the multi-column index (which is a good idea), be sure that "id"
> is the last of the three columns, since that's the column on which you have
> an inequality test rather than an equality test; eg,
> (company_id,source_model_name,id).
>
Interesting. I would have thought the order o
> It probably thinks the id check is going to be better to limit the result
> set.
>
> How many records are there for id > 1935759 ?
About 40 million or so.
> vs
> How many records for company_id = 4 and source_model_name =
> 'CommissionedVisit' ?
>
> If this is a common query you could probably
On Thu, Oct 1, 2009 at 10:04 PM, Chris wrote:
> Tim Uckun wrote:
>
> If this is a common query you could probably do a multi-column index on all
> 3 columns (id, company_id, source_model_name) - but if company_id and
> source_model_name have a low number of distinct values, then it's not going
>
Tim Uckun wrote:
I have a pretty simple query on a pretty simple table with about 60
million records in it.
This is the query.
SELECT * FROM "changes" WHERE (id > 1935759 and company_id = 4 and
source_model_name = 'CommissionedVisit') ORDER BY id ASC LIMIT 1
The id field is the primary key. T
