Re: why is a constraint not 'pushed down' into a subselect when this subselect is using a 'group by' ?? - Mailing list pgsql-performance

From Tom Lane
Subject Re: why is a constraint not 'pushed down' into a subselect when this subselect is using a 'group by' ??
Date
Msg-id 296.1087305799@sss.pgh.pa.us
Whole thread Raw
In response to why is a constraint not 'pushed down' into a subselect when this subselect is using a 'group by' ??  (Frank van Vugt <ftm.van.vugt@foxi.nl>)
Responses Re: why is a constraint not 'pushed down' into a subselect when this subselect is using a 'group by' ??
List pgsql-performance
Frank van Vugt <ftm.van.vugt@foxi.nl> writes:
> If I ditch the group by, then this contraint does get pushed into the
> subselect :

You're misinterpreting it.  Without the group by, the plan is a
candidate for nestloop-with-inner-index-scan; with the group by,
there's another step in the way.

Pushing down into subselects does get done, for instance in CVS tip
I can change the last part of your query to "foo.article_id < 50"
and get

 Hash Join  (cost=25.18..53.53 rows=335 width=8)
   Hash Cond: ("outer".id = "inner".article_id)
   ->  Seq Scan on article  (cost=0.00..20.00 rows=1000 width=4)
   ->  Hash  (cost=25.01..25.01 rows=67 width=8)
         ->  Subquery Scan foo  (cost=24.17..25.01 rows=67 width=8)
               ->  HashAggregate  (cost=24.17..24.34 rows=67 width=8)
                     ->  Seq Scan on package  (cost=0.00..22.50 rows=334 width=8)
                           Filter: (article_id < 50)

Obviously this is on toy tables, but the point is that the constraint
does get pushed down through the GROUP BY when appropriate.

            regards, tom lane


pgsql-performance by date:

Previous
From: "Jeremy Dunn"
Date:
Subject: Re: 50 000 000 Table entries and I have to do a keyword search HELP NEEDED
Next
From: Tom Lane
Date:
Subject: Re: Index oddity (still)