Re: Yet another question on LIMIT performance :/ - Mailing list pgsql-performance

From Tom Lane
Subject Re: Yet another question on LIMIT performance :/
Date
Msg-id 10614.1162823582@sss.pgh.pa.us
Whole thread Raw
In response to Re: Yet another question on LIMIT performance :/  ("Heikki Linnakangas" <heikki@enterprisedb.com>)
List pgsql-performance
"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

pgsql-performance by date:

Previous
From: Madison Kelly
Date:
Subject: Re: Setting "nice" values
Next
From: "Carlos H. Reimer"
Date:
Subject: Context switching