"Heikki Linnakangas" <heikki@xxxxxxxxxxxxxxxx> 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
