Re: 9.3 Pre-proposal: Range Merge Join
От | Tom Lane |
---|---|
Тема | Re: 9.3 Pre-proposal: Range Merge Join |
Дата | |
Msg-id | 7344.1334617515@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Re: 9.3 Pre-proposal: Range Merge Join (Robert Haas <robertmhaas@gmail.com>) |
Ответы |
Re: 9.3 Pre-proposal: Range Merge Join
|
Список | pgsql-hackers |
Robert Haas <robertmhaas@gmail.com> writes: > On Apr 16, 2012, at 1:40 AM, Jeff Davis <pgsql@j-davis.com> wrote: >> See attached SQL for example. The >> Problem statement: slow. Nested loops are the only option, although they >> can benefit from an inner GiST index if available. But if the join is >> happening up in the plan tree somewhere, then it's impossible for any >> index to be available. > Hmm. This sounds like something that Tom's recent work on > parameterized plans ought to have fixed, or if not, it seems closely > related. Not really. It's still going to be a nestloop, and as such not terribly well suited for queries where there are a lot of matchable rows on both sides. The work I've been doing is really about making nestloops usable in cases where join order restrictions formerly prevented it --- but Jeff's complaint has nothing to do with that. (This thought also makes me a bit dubious about the nearby suggestions that more indexes will fix it.) regards, tom lane
В списке pgsql-hackers по дате отправления: