Re: plan time of MASSIVE partitioning ...

On Fri, Nov 12, 2010 at 10:55 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> Bruce Momjian <bruce@momjian.us> writes:
>> FYI, I always wondered if the rare use of mergejoins justified the extra
>> planning time of carrying around all those joinpaths.
>
> They're hardly rare.

They fairly rare in the sorts of queries I normally issue, but I'd
quibble with the statement on other grounds: IME, we generate far more
nest loops paths than anything else.  The comment in
match_unsorted_outer() says it all:
* We always generate a nestloop path for each available outer path.* In fact we may generate as many as five: one on
thecheapest-total-cost* inner path, one on the same with materialization, one on the* cheapest-startup-cost inner path
(ifdifferent), one on the* cheapest-total inner-indexscan path (if any), and one on the* cheapest-startup
inner-indexscanpath (if different).
 

-- 
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company