Re: why is a constraint not 'pushed down' into a subselect when this subselect is using a 'group by' ??
От | Tom Lane |
---|---|
Тема | Re: why is a constraint not 'pushed down' into a subselect when this subselect is using a 'group by' ?? |
Дата | |
Msg-id | 296.1087305799@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | 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>) |
Ответы |
Re: why is a constraint not 'pushed down' into a subselect when this subselect is using a 'group by' ??
|
Список | 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 по дате отправления: