rm_pg@cheapcomplexdevices.com writes:
> On Mon, 5 Dec 2005, Tom Lane wrote:
>> (Note to self: it is a bit odd that fac_id=261 is pushed down to become
>> an indexqual in one case but not the other ...)
> I speculate that the seq_scan wasn't really the slow part
> compared to not using using both parts of the index in the
> second part of the plan. The table point_features is tens of
> thousands of rows, while the table facets is tens of millions.
Agreed, but it's still odd that it would use a seqscan in one case and
not the other.
I found the reason why the fac_id=261 clause isn't getting used as an
index qual; it's a bit of excessive paranoia that goes back to 2002.
I've fixed that for 8.1.1, but am still wondering about the seqscan
on the other side of the join.
regards, tom lane
