To: "Kevin Grittner" <Kevin.Grittner@wicourts.gov>
cc: heikki.linnakangas@enterprisedb.com, Jayadevan.Maymala@ibsplc.com,
	pgsql-performance@postgresql.org, pgsql-performance-owner@postgresql.org
Subject: Re: Query performance issue 
In-reply-to: <4E6345520200002500040BD6@gw.wicourts.gov> 
References: <4E6345520200002500040BD6@gw.wicourts.gov>
Comments: In-reply-to "Kevin Grittner" <Kevin.Grittner@wicourts.gov>
	message dated "Sun, 04 Sep 2011 09:30:58 -0500"
Date: Sun, 04 Sep 2011 11:18:19 -0400
Message-ID: <12017.1315149499@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>

"Kevin Grittner" <Kevin.Grittner@wicourts.gov> writes:
> Thanks for posting the query and related schema.  I tried working
> through it, but I keep coming back to this sort, and wondering how a
> sort can have 1121 rows as input and 2673340321 rows as output.  Does
> anyone have any ideas on what could cause that?

Mergejoin rescan.  There really are only 1121 rows in the data, but
the parent merge join is pulling them over and over again --- evidently
there are a lot of equal keys in the data.  The EXPLAIN ANALYZE
machinery counts each fetch as a new row, even after a mark/restore.

The planner does know about that effect and will penalize merge joins
when it realizes there are a lot of duplicate keys in the input.  In
this case I'm thinking that the drastic underestimate of the size of the
other side of the join results in not penalizing the merge enough.

(On the other hand, hash joins don't like equal keys that much either...)

			regards, tom lane