From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Mark Halliwell <mark(at)transportservices(dot)com(dot)au> |
Cc: | pgsql-performance(at)postgresql(dot)org |
Subject: | Re: Query not using the index |
Date: | 2003-02-25 15:13:26 |
Message-ID: | 10478.1046186006@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-performance |
Mark Halliwell <mark(at)transportservices(dot)com(dot)au> writes:
> The majority of records (about 6.8 million) have computer = 8 with sequence
> starting at 2200000 and incrementing by 1.
> There are about 497000 records with computer = 3 with the sequence starting at
> 1 and also incrementing by 1.
> There are only a few records with other computer numbers.
You aren't going to find any non-kluge solution, because Postgres keeps
no cross-column statistics and thus is quite unaware that there's any
correlation between the computer and sequence fields. So in a query
like
> select * from replicate where computer = 3 and sequence >= 490000;
the sequence constraint looks extremely unselective to the planner, and
you get a seqscan, even though *in the domain of computer = 3* it's a
reasonably selective constraint.
> that if a specify an upper limit for sequence (a value which I cannot always
> easily predict), it also uses the index.
I would think that it'd be sufficient to say
select * from replicate where computer = 3 and sequence >= 490000
and sequence < 2200000;
If it's not, try increasing the statistics target for the sequence
column so that ANALYZE gathers a finer-grain histogram for that column.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Robert Treat | 2003-02-25 15:28:02 | Re: slow query |
Previous Message | Bruno Wolff III | 2003-02-25 13:56:29 | Re: Query not using the index |