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