Re: Efficient sorting the results of a join, without denormalization

From: "Glen M(dot) Witherington" <glen(at)fea(dot)st>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: pgsql-general(at)postgresql(dot)org
Subject: Re: Efficient sorting the results of a join, without denormalization
Date: 2015-05-31 09:50:00
Message-ID: 1433065800.2087822.282614753.2E44CE56@webmail.messagingengine.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general

On Sun, May 31, 2015, at 12:53 AM, Tom Lane wrote:
> "Glen M. Witherington" <glen(at)fea(dot)st> writes:
> > And here's the query I want to do, efficiently:
>
> > SELECT * FROM c
> > JOIN b ON b.id = c.b_id
> > JOIN a ON a.id = b.a_id
> > WHERE a.id = 3
> > ORDER BY b.created_at DESC
> > LIMIT 10
>
> At least for that dummy data, this seems sufficient:
>
> regression=# create index on b (a_id, created_at);
> CREATE INDEX
> regression=# explain analyze SELECT * FROM c
> JOIN b ON b.id = c.b_id
> JOIN a ON a.id = b.a_id
> WHERE a.id = 3
> ORDER BY b.created_at DESC
> LIMIT 10;
> QUERY
> PLAN
> ------------------------------------------------------------------------------------------------------------------------------------------------------
> Limit (cost=0.14..21.95 rows=10 width=64) (actual time=0.064..1.176
> rows=10 loops=1)
> -> Nested Loop (cost=0.14..436079.81 rows=200000 width=64) (actual
> time=0.063..1.173 rows=10 loops=1)
> Join Filter: (b.id = c.b_id)
> Rows Removed by Join Filter: 1218
> -> Nested Loop (cost=0.14..9.81 rows=20 width=40) (actual
> time=0.035..0.035 rows=1 loops=1)
> -> Index Scan Backward using b_a_id_created_at_idx on b
> (cost=0.14..8.49 rows=20 width=24) (actual
> time=0.019..0.019 rows=1 loops=1)
> Index Cond: (a_id = 3)
> -> Materialize (cost=0.00..1.07 rows=1 width=16) (actual
> time=0.013..0.013 rows=1 loops=1)
> -> Seq Scan on a (cost=0.00..1.06 rows=1 width=16)
> (actual time=0.009..0.009 rows=1 loops=1)
> Filter: (id = 3)
> Rows Removed by Filter: 2
> -> Materialize (cost=0.00..27230.00 rows=1000000 width=24)
> (actual time=0.008..0.811 rows=1228 loops=1)
> -> Seq Scan on c (cost=0.00..16370.00 rows=1000000
> width=24) (actual time=0.007..0.310 rows=1228 loops=1)
> Planning time: 0.796 ms
> Execution time: 1.390 ms
> (15 rows)
>
> regards, tom lane

Wow, sorry I screwed up the query. It should be:

ORDER BY c.created_at DESC

Not b, or as you noted its trivial to index. Sorry!

In response to

Responses

Browse pgsql-general by date

  From Date Subject
Next Message Robert Haas 2015-05-31 11:51:59 Re: Re: [GENERAL] 9.4.1 -> 9.4.2 problem: could not access status of transaction 1
Previous Message Zenaan Harkness 2015-05-31 09:44:08 advocating LTS release and feature-train release cycles