mark <markkicks@gmail.com> writes:
> EXPLAIN ANALYZE select * from pokes where uid = 578439028 order by id
> DESC limit 6;
> QUERY PLAN
>
----------------------------------------------------------------------------------------------------------------------------------------------------
> Limit (cost=0.00..9329.02 rows=6 width=135) (actual
> time=13612.247..13612.247 rows=0 loops=1)
> -> Index Scan Backward using pokes_pkey on pokes
> (cost=0.00..5182270.69 rows=3333 width=135) (actual
> time=13612.245..13612.245 rows=0 loops=1)
> Filter: (uid = 578439028)
> Total runtime: 13612.369 ms
> (4 rows)
The problem is the vast disconnect between the estimated and actual
rowcounts for the indexscan (3333 vs 0). The planner thinks there
are three thousand rows matching uid = 578439028, and that encourages
it to try a plan that's only going to be fast if at least six such
rows show up fairly soon while scanning the index in reverse id order.
What you really want it to do here is scan on the uid index and then
sort the result by id ... but that will be slow in exactly the case
where this plan is fast, ie, when there are a lot of matching uids.
Bottom line: the planner cannot make the right choice between these
alternatives unless it's got decent statistics about the frequency
of uid values. "I analyzed the table about a week ago" is not good
enough maintenance policy --- you need current stats, and you might need
to bump up the statistics target to get enough data about less-common
values of uid.
(Since it's 8.3, the autovac daemon might have been analyzing for you,
if you didn't turn off autovacuum. In that case increasing the
statistics target is the first thing to try.)
regards, tom lane
