From: Tom Lane <tgl@sss.pgh.pa.us>
To: Heikki Linnakangas <heikki@enterprisedb.com>
Cc: Hannes Dorbath <light@theendofthetunnel.de>
Cc: pgsql-performance@postgresql.org
Subject: Re: Yet another question on LIMIT performance :/
Date: Mon, 06 Nov 2006 09:33:02 -0500
Message-ID: <10614.1162823582@sss.pgh.pa.us> (raw)
In-Reply-To: <454F42FF.3070901@enterprisedb.com>
References: <einfmm$r41$1@news.hub.org>
<454F42FF.3070901@enterprisedb.com>
"Heikki Linnakangas" <heikki@enterprisedb.com> writes:
> Hannes Dorbath wrote:
>> Though it should only have to join a few rows it seems to scan all rows.
> What makes you think that's the case?
What it looks like to me is that the range of keys present in
pk_revisions_active corresponds to just the upper end of the range of
keys present in pk_revisions (somehow not too surprising). So the
mergejoin isn't the most effective plan possible for this case --- it
has to scan through much of pk_revisions before it starts getting
matches. The planner doesn't have any model for that though, and is
costing the plan on the assumption of uniformly-distributed matches.
A nestloop plan would be faster for this specific case, but much
slower if a large number of rows were requested.
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, heikki@enterprisedb.com, light@theendofthetunnel.de
Subject: Re: Yet another question on LIMIT performance :/
In-Reply-To: <10614.1162823582@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