Re: optimizer picks smaller table to drive nested loops?

I said:
> 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.

Indeed, after fixing the unrealistic estimate for SubqueryScan, I get
this:

regression=# explain analyze select * from tenk1, (select 1 union all select 2) as x;
QUERY PLAN
------------------------------------------------------------------------------------------------------------------------------
Nested Loop (cost=0.06..858.06 rows=20000 width=248) (actual time=0.25..1448.19 rows=20000 loops=1)
-> Seq Scan on tenk1 (cost=0.00..458.00 rows=10000 width=244) (actual time=0.06..162.48 rows=10000 loops=1)
-> Materialize (cost=0.06..0.08 rows=2 width=4) (actual time=0.01..0.03 rows=2 loops=10000)
-> Subquery Scan x (cost=0.00..0.06 rows=2 width=4) (actual time=0.10..0.27 rows=2 loops=1)
-> Append (cost=0.00..0.04 rows=2 width=0) (actual time=0.07..0.20 rows=2 loops=1)
-> Subquery Scan "*SELECT* 1" (cost=0.00..0.02 rows=1 width=0) (actual time=0.05..0.08 rows=1 loops=1)
-> Result (cost=0.00..0.01 rows=1 width=0) (actual time=0.03..0.03 rows=1 loops=1)
-> Subquery Scan "*SELECT* 2" (cost=0.00..0.02 rows=1 width=0) (actual time=0.03..0.06 rows=1 loops=1)
-> Result (cost=0.00..0.01 rows=1 width=0) (actual time=0.01..0.02 rows=1 loops=1)
Total runtime: 1627.26 msec
(10 rows)

which is probably the best way to do it, all things considered.

regards, tom lane