| From: | Robert Haas <robertmhaas(at)gmail(dot)com> |
|---|---|
| To: | Jeff Davis <pgsql(at)j-davis(dot)com> |
| Cc: | "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org> |
| Subject: | Re: 9.3 Pre-proposal: Range Merge Join |
| Date: | 2012-04-16 22:20:38 |
| Message-ID: | BE156338-2EE4-4830-9C97-B685AB6CAFB4@gmail.com |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On Apr 16, 2012, at 1:40 AM, Jeff Davis <pgsql(at)j-davis(dot)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. And by "this" I mean specifically the ability to use a GiST index to drive a nested loop that is higher up in the plan tree than the immediate parent of the index scan.
This is not an argument against your proposal, just an observation.
...Robert
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Joshua D. Drake | 2012-04-16 23:01:39 | Re: Bug tracker tool we need |
| Previous Message | Jay Levitt | 2012-04-16 21:52:54 | Re: 9.3 Pre-proposal: Range Merge Join |