From: Tom Lane <tgl@sss.pgh.pa.us>
To: Matthew <matthew@flymine.org>
Cc: pgsql-performance@postgresql.org
Subject: Re: TB-sized databases
Date: Thu, 06 Dec 2007 13:34:47 -0500
Message-ID: <18104.1196966087@sss.pgh.pa.us> (raw)
In-Reply-To: <Pine.LNX.4.58.0712061758360.3731@aragorn.flymine.org>
References: <4544e0330711260904g45d893a8ub1731e245aa8fc84@mail.gmail.com>
<13851.1196351131@sss.pgh.pa.us>
<1196352866.4246.1304.camel@ebony.site>
<200712051507.22745.xzilla@users.sourceforge.net>
<1196933896.4255.340.camel@ebony.site>
<20071206154212.GP5294@mathom.us>
<15753.1196957598@sss.pgh.pa.us>
<Pine.LNX.4.58.0712061626370.3731@aragorn.flymine.org>
<17456.1196963738@sss.pgh.pa.us>
<Pine.LNX.4.58.0712061758360.3731@aragorn.flymine.org>
Matthew <matthew@flymine.org> writes:
> On Thu, 6 Dec 2007, Tom Lane wrote:
>> Hmm. IIRC, there are smarts in there about whether a mergejoin can
>> terminate early because of disparate ranges of the two join variables.
> Very cool. Would that be a planner cost estimate fix (so it avoids the
> merge join), or a query execution fix (so it does the merge join on the
> table subset)?
Cost estimate fix. Basically what I'm thinking is that the startup cost
attributed to a mergejoin ought to account for any rows that have to be
skipped over before we reach the first join pair. In general this is
hard to estimate, but for mergejoin it can be estimated using the same
type of logic we already use at the other end.
After looking at the code a bit, I'm realizing that there's actually a
bug in there as of 8.3: mergejoinscansel() is expected to be able to
derive numbers for either direction of scan, but if it's asked to
compute numbers for a DESC-order scan, it looks for a pg_stats entry
sorted with '>', which isn't gonna be there. It needs to know to
look for an '<' histogram and switch the min/max. So the lack of
symmetry here is causing an actual bug in logic that already exists.
That makes the case for fixing this now a bit stronger ...
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
Subject: Re: TB-sized databases
In-Reply-To: <18104.1196966087@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