On Apr 16, 2012, at 1:40 AM, Jeff Davis <pg...@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. 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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
