From: Tom Lane <tgl@sss.pgh.pa.us>
To: Matthew Wakeling <matthew@flymine.org>
Cc: Scott Marlowe <scott.marlowe@gmail.com>
Cc: pgsql-performance@postgresql.org
Subject: Re: merge join killing performance
Date: Wed, 19 May 2010 12:53:03 -0400
Message-ID: <21497.1274287983@sss.pgh.pa.us> (raw)
In-Reply-To: <alpine.DEB.2.00.1005182254110.1867@aragorn.flymine.org>
References: <AANLkTikmwxQJIDfefCoK_SQN2DTwQs1naLwS-RW8PgRU@mail.gmail.com>
<alpine.DEB.2.00.1005182254110.1867@aragorn.flymine.org>
Matthew Wakeling <matthew@flymine.org> writes:
> On Tue, 18 May 2010, Scott Marlowe wrote:
>> Aggregate (cost=902.41..902.42 rows=1 width=4)
>> -> Merge Join (cost=869.97..902.40 rows=1 width=4)
>> Merge Cond: (f.eid = ev.eid)
>> -> Index Scan using files_eid_idx on files f
>> (cost=0.00..157830.39 rows=3769434 width=8)
> Okay, that's weird. How is the cost of the merge join only 902, when the
> cost of one of the branches 157830, when there is no LIMIT?
It's apparently estimating (wrongly) that the merge join won't have to
scan very much of "files" before it can stop because it finds an eid
value larger than any eid in the other table. So the issue here is an
inexact stats value for the max eid.
regards, tom lane
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: pgsql-performance@postgresql.org
Cc: tgl@sss.pgh.pa.us, matthew@flymine.org, scott.marlowe@gmail.com
Subject: Re: merge join killing performance
In-Reply-To: <21497.1274287983@sss.pgh.pa.us>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox