Re: optimizer picks smaller table to drive nested loops?

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