Gregory Stark <st...@enterprisedb.com> writes: > I don't really understand what's going on here.
It's flattening the sub-select, converting select sum(n),sum(n) from (select (select count(*) as n from a ) as n from (select random() as s) as xyzzy) as xyzzy ; to select sum((select count(*) from a)), sum((select count(*) from a)) from (select random() as s) as xyzzy; Maybe we could stop it from doing that when there are sub-selects in the sub-select's targetlist, but I'm afraid that would make other cases worse. BTW, in CVS HEAD it looks like this regression=# explain verbose select sum(n),sum(n) from (select (select count(*) as n from a ) as n from (select random() as s) as xyzzy) as xyzzy ; QUERY PLAN ------------------------------------------------------------------- Aggregate (cost=80.06..80.07 rows=1 width=0) Output: sum($0), sum($1) InitPlan 1 (returns $0) -> Aggregate (cost=40.00..40.01 rows=1 width=0) Output: count(*) -> Seq Scan on a (cost=0.00..34.00 rows=2400 width=0) Output: public.a.f1 InitPlan 2 (returns $1) -> Aggregate (cost=40.00..40.01 rows=1 width=0) Output: count(*) -> Seq Scan on a (cost=0.00..34.00 rows=2400 width=0) Output: public.a.f1 -> Result (cost=0.00..0.01 rows=1 width=0) Output: random() (14 rows) which makes it at least a little clearer where the subplans are connected to ... regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers