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 12:55:38 -0500
Message-ID: <17456.1196963738@sss.pgh.pa.us> (raw)
In-Reply-To: <Pine.LNX.4.58.0712061626370.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>
Matthew <matthew@flymine.org> writes:
> ... For this query, Postgres would perform a nested loop,
> iterating over all rows in the small table, and doing a hundred index
> lookups in the big table. This completed very quickly. However, adding the
> LIMIT meant that suddenly a merge join was very attractive to the planner,
> as it estimated the first row to be returned within milliseconds, without
> needing to sort either table.
> The problem is that Postgres didn't know that the first hit in the big
> table would be about half-way through, after doing a index sequential scan
> for half a bazillion rows.
Hmm. IIRC, there are smarts in there about whether a mergejoin can
terminate early because of disparate ranges of the two join variables.
Seems like it should be straightforward to fix it to also consider
whether the time-to-return-first-row will be bloated because of
disparate ranges. I'll take a look --- but it's probably too late
to consider this for 8.3.
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: <17456.1196963738@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