Re: strange explain analyze output - Mailing list pgsql-general

From Jeff Davis
Subject Re: strange explain analyze output
Date
Msg-id 1219941275.8211.112.camel@jdavis
Whole thread Raw
In response to Re: strange explain analyze output  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: strange explain analyze output  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-general
On Thu, 2008-08-28 at 00:42 -0400, Tom Lane wrote:
> The reason that these statements are not inconsistent is that the
> Sort is the inner relation for a mergejoin.  In the presence of
> duplicate keys in the outer relation, a mergejoin will "rewind" and
> rescan duplicate keys in the inner relation; that is, any row in the
> inner relation will be fetched approximately as many times as it has
> matches in the outer relation.  So it looks like you've got roughly
> 1000X duplication in these tables?
>

Thanks for the explanation.

> (BTW, the planner knows that this is expensive and will avoid mergejoins
> when there are many duplicate keys.  But apparently a hash join seemed
> even worse for the stats of this particular pair of tables.)
>

Then wouldn't the planner have estimated more rows returned by the sort
(including rescanned rows) than the HashAgg? It estimated exactly the
same number as it estimated for the output of the HashAgg.

Regards,
    Jeff Davis


pgsql-general by date:

Previous
From: Andrew Sullivan
Date:
Subject: Re: Vaccuum best practice: cronjob or autovaccuum?
Next
From: "John T. Dow"
Date:
Subject: Re: WAL file questions - how to relocate on Windows, how to replay after total loss, etc