From: | "Christopher Kings-Lynne" <chriskl(at)familyhealth(dot)com(dot)au> |
---|---|
To: | "Tom Lane" <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | "Stephan Szabo" <sszabo(at)megazone23(dot)bigpanda(dot)com>, "MindTerm" <mindterm(at)yahoo(dot)com>, <pgsql-sql(at)postgresql(dot)org> |
Subject: | 'IN' performance |
Date: | 2001-12-17 06:33:40 |
Message-ID: | GNELIHDDFBOCMGBFGEFOEENFCAAA.chriskl@familyhealth.com.au |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-sql |
> In the sub-select form, we pretty much suck: for each tuple in the outer
> query, we run the inner query until we find a matching value or the
> inner query ends. This is basically a nested-loop scenario, with the
> only (minimally) redeeming social value being that the planner realizes
> it should pick a fast-start plan for the inner query. I think it should
> be possible to convert this form into a modified kind of join (sort of
> the reverse of an outer join: rather than at least one result per
> lefthand row, at most one result per lefthand row), and then we could
> use join methods that are more efficient than nested-loop. But no one's
> tried to make that happen yet.
That's what I was thinking...where abouts does all that activity happen?
I assume the planner knows that it doesn't have to reevaluate the subquery
if it's not correlated?
Chris
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2001-12-17 06:44:03 | Re: 'IN' performance |
Previous Message | Tom Lane | 2001-12-17 06:21:16 | Re: performance tuning in large function / transaction |