On Fri, Nov 12, 2010 at 10:55 PM, Tom Lane <t...@sss.pgh.pa.us> wrote: > Bruce Momjian <br...@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 the cheapest-total-cost * inner path, one on the same with materialization, one on the * cheapest-startup-cost inner path (if different), one on the * cheapest-total inner-indexscan path (if any), and one on the * cheapest-startup inner-indexscan path (if different). -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
