Re: Missed index opportunity for outer join?

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: rm_pg(at)cheapcomplexdevices(dot)com
Cc: pgsql-performance(at)postgresql(dot)org
Subject: Re: Missed index opportunity for outer join?
Date: 2005-12-06 16:57:19
Message-ID: 4678.1133888239@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-performance

rm_pg(at)cheapcomplexdevices(dot)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

In response to

Responses

Browse pgsql-performance by date

  From Date Subject
Next Message Michael Riess 2005-12-06 16:59:14 Re: TSearch2 vs. Apache Lucene
Previous Message Joshua Kramer 2005-12-06 16:47:44 TSearch2 vs. Apache Lucene