Greg Stark <gsstark@mit.edu> writes:
> Tom Lane <tgl@sss.pgh.pa.us> writes:
>> However, it looks to me like the subquery-scan-outside plan probably
>> is the faster one, on both my machine and yours. I get
> Woah, that's pretty whacky. It seems like it ought to be way faster to do a
> single sequential scan and return two records for each tuple read rather than
> do an entire unnecessary sequential scan, even if most or even all of the
> second one is cached.
The problem is the CPU expense of executing "SELECT 1 UNION SELECT 2"
over and over. Doing that for every row of the outer table adds up.
We were both testing on relatively small tables --- I suspect the
results would be different if the outer table were too large to fit
in disk cache.
I am not sure why the planner did not choose to stick a Materialize
node atop the Subquery Scan, though. It looks to me like it should
have considered that option --- possibly the undercharging for Subquery
Scan is the reason it wasn't chosen.
regards, tom lane
