From: Tom Lane <tgl@sss.pgh.pa.us>
To: mark <markkicks@gmail.com>
Cc: pgsql-general@postgresql.org
Subject: Re: select query takes 13 seconds to run with index
Date: Mon, 26 May 2008 20:36:10 -0400
Message-ID: <18458.1211848570@sss.pgh.pa.us> (raw)
In-Reply-To: <82fa9e310805261549m2362fbe8sbf18789938fee833@mail.gmail.com>
References: <82fa9e310805261549m2362fbe8sbf18789938fee833@mail.gmail.com>
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
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: pgsql-performance@postgresql.org
Cc: tgl@sss.pgh.pa.us, markkicks@gmail.com, pgsql-general@postgresql.org
Subject: Re: select query takes 13 seconds to run with index
In-Reply-To: <18458.1211848570@sss.pgh.pa.us>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox