Re: optimizer picks smaller table to drive nested loops?

Greg Stark <gsstark(at)mit(dot)edu> writes:
> Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)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