Skip site navigation (1) Skip section navigation (2)

Re: Inner join vs where-clause subquery

From: Richard Huxton <dev(at)archonet(dot)com>
To: Jeremy Haile <jhaile(at)fastmail(dot)fm>
Cc: pgsql-performance(at)postgresql(dot)org
Subject: Re: Inner join vs where-clause subquery
Date: 2006-12-19 20:02:35
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-performance
Jeremy Haile wrote:
> Here's the query and explain analyze using the result of the sub-query
> substituted: 
> explain analyze select min(nlogid) as start_nlogid,
>        max(nlogid) as end_nlogid,
>        min(dtCreateDate) as start_transaction_timestamp,
>        max(dtCreateDate) as end_transaction_timestamp
> from activity_log_facts
> where nlogid > 478287801
> and dtCreateDate < '2006-12-18 9:10'
> Aggregate  (cost=657.37..657.38 rows=1 width=12) (actual
> time=0.018..0.019 rows=1 loops=1)
>   ->  Index Scan using activity_log_facts_nlogid_idx on
>   activity_log_facts  (cost=0.00..652.64 rows=472 width=12) (actual
>   time=0.014..0.014 rows=0 loops=1)
>         Index Cond: (nlogid > 478287801)
>         Filter: (dtcreatedate < '2006-12-18 09:10:00'::timestamp without
>         time zone)
> Total runtime: 0.076 ms
> Sorry if the reason should be obvious, but I'm not the best at
> interpreting the explains.  Why is this explain so much simpler than the
> other query plan (with the subquery)?

Because it's planning it with knowledge of what "nlogid"s it's filtering 
by. It knows it isn't going to get many rows back with nlogid > 
478287801. In your previous explain it thought a large number of rows 
would match and was trying not to sequentially scan the 
activity_log_facts table.

Ideally, the planner would evaluate the subquery in your original form 
(it should know it's only getting one row back from max()). Then it 
could plan the query as above. I'm not sure how tricky that is to do though.

   Richard Huxton
   Archonet Ltd

In response to


pgsql-performance by date

Next:From: Jeremy HaileDate: 2006-12-19 20:18:07
Subject: Re: Inner join vs where-clause subquery
Previous:From: Jeremy HaileDate: 2006-12-19 19:34:50
Subject: Re: Inner join vs where-clause subquery

Privacy Policy | About PostgreSQL
Copyright © 1996-2017 The PostgreSQL Global Development Group