pg.ddx.io pgsql-performance@postgresql.org mailing list archive
help / color / mirror / Atom feedLIMIT 1 poor query plan
3+ messages / 2 participants
[nested] [flat]
* LIMIT 1 poor query plan
@ 2015-10-10 08:52 Marcio Ribeiro <mribeiro@gmail.com>
0 siblings, 1 reply; 3+ messages in thread
From: Marcio Ribeiro @ 2015-10-10 08:52 UTC (permalink / raw)
To: pgsql-performance
Hail there,
Short question:
Why would pg optimizer choose a worst (slower) query plan for a
query with 'LIMIT 1' instead of, say, 'LIMIT 3'?
Complete scenario:
Query: 'SELECT * FROM a WHERE a.b_id = 42 ORDER BY created LIMIT 1'
- b_id is a FK to b;
- created is a datetime with the time of the creation of the row;
- both 'b' and 'created' are indexed separately
This query, with the LIMIT 1, uses the index on created, which is much
slower (10x) than if it used the index on b_id
If I change the LIMIT from 1 to 3 pg starts using the index on b_id.
Already tried running REINDEX and VACUUM ANALYZE on both A and B.
Nothing changed.
Why does this happen?
Is there any way I can hint/force the optimizer to use b_id index?
Thanks
--
Marcio Ribeiro
^ permalink raw reply [nested|flat] 3+ messages in thread
* Re: LIMIT 1 poor query plan
@ 2015-10-10 15:45 Tom Lane <tgl@sss.pgh.pa.us>
parent: Marcio Ribeiro <mribeiro@gmail.com>
0 siblings, 1 reply; 3+ messages in thread
From: Tom Lane @ 2015-10-10 15:45 UTC (permalink / raw)
To: Marcio Ribeiro <mribeiro@gmail.com>; +Cc: pgsql-performance
Marcio Ribeiro <mribeiro@gmail.com> writes:
> Short question:
> Why would pg optimizer choose a worst (slower) query plan for a
> query with 'LIMIT 1' instead of, say, 'LIMIT 3'?
> Complete scenario:
> Query: 'SELECT * FROM a WHERE a.b_id = 42 ORDER BY created LIMIT 1'
> - b_id is a FK to b;
> - created is a datetime with the time of the creation of the row;
> - both 'b' and 'created' are indexed separately
> This query, with the LIMIT 1, uses the index on created, which is much
> slower (10x) than if it used the index on b_id
It's trying to avoid a sort; or to be less anthropomorphic, the estimated
cost of scanning the "created" index until it hits the first row with
b_id=42 is less than the estimated cost of collecting all the rows with
b_id=42 and then sorting them by "created". The estimates unfortunately
are kind of shaky because it's hard to predict how many rows will get
skipped before finding one with b_id=42.
If you do this type of query often enough to care about its performance,
you could consider creating a two-column index on (b_id, created)
(in that order).
regards, tom lane
--
Sent via pgsql-performance mailing list (pgsql-performance@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-performance
^ permalink raw reply [nested|flat] 3+ messages in thread
* Re: LIMIT 1 poor query plan
@ 2015-10-10 17:45 Marcio Ribeiro <mribeiro@gmail.com>
parent: Tom Lane <tgl@sss.pgh.pa.us>
0 siblings, 0 replies; 3+ messages in thread
From: Marcio Ribeiro @ 2015-10-10 17:45 UTC (permalink / raw)
To: Tom Lane <tgl@sss.pgh.pa.us>; +Cc: pgsql-performance
Yes, the composite index nailed it.
Thanks mate :)
On Sat, Oct 10, 2015 at 12:45 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> Marcio Ribeiro <mribeiro@gmail.com> writes:
> > Short question:
> > Why would pg optimizer choose a worst (slower) query plan for a
> > query with 'LIMIT 1' instead of, say, 'LIMIT 3'?
>
> > Complete scenario:
> > Query: 'SELECT * FROM a WHERE a.b_id = 42 ORDER BY created LIMIT 1'
> > - b_id is a FK to b;
> > - created is a datetime with the time of the creation of the row;
> > - both 'b' and 'created' are indexed separately
>
> > This query, with the LIMIT 1, uses the index on created, which is much
> > slower (10x) than if it used the index on b_id
>
> It's trying to avoid a sort; or to be less anthropomorphic, the estimated
> cost of scanning the "created" index until it hits the first row with
> b_id=42 is less than the estimated cost of collecting all the rows with
> b_id=42 and then sorting them by "created". The estimates unfortunately
> are kind of shaky because it's hard to predict how many rows will get
> skipped before finding one with b_id=42.
>
> If you do this type of query often enough to care about its performance,
> you could consider creating a two-column index on (b_id, created)
> (in that order).
>
> regards, tom lane
>
--
Marcio Ribeiro
^ permalink raw reply [nested|flat] 3+ messages in thread
end of thread, other threads:[~2015-10-10 17:45 UTC | newest]
Thread overview: 3+ messages (download: mbox mbox.gz follow: Atom feed)
-- links below jump to the message on this page --
2015-10-10 08:52 LIMIT 1 poor query plan Marcio Ribeiro <mribeiro@gmail.com>
2015-10-10 15:45 ` Tom Lane <tgl@sss.pgh.pa.us>
2015-10-10 17:45 ` Marcio Ribeiro <mribeiro@gmail.com>
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