Re: Changing SQL Inlining Behaviour (or...?) - Mailing list pgsql-hackers

From Tom Lane
Subject Re: Changing SQL Inlining Behaviour (or...?)
Date
Msg-id 29368.1547953418@sss.pgh.pa.us
Whole thread Raw
In response to Re: Changing SQL Inlining Behaviour (or...?)  (Paul Ramsey <pramsey@cleverelephant.ca>)
Responses Re: Changing SQL Inlining Behaviour (or...?)  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
Paul Ramsey <pramsey@cleverelephant.ca> writes:
> On Jan 19, 2019, at 5:53 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
>> [ maybe what we need is special index operators for extensions ]

> While I’m not 100% sure what this new thing would “look like” there are at least a few quirky variations on the
patternyou’ve correctly identified. So, ST_Intersects(a, b), ST_Contains(a, b) these all match the pattern. 

> One that is similar but not quite matching is ST_DWithin(a, b, radius), which expands to
> a && expand(b, radius) and b && expand(a, radius) and _ST_DWithin(a, b, radius)
> so the operator call is doubled up and includes a function all on one operand rather than a bare call.

Hm.  That seems like it could be made to fit the pattern.  The basic
charter of the transform function I have in mind would be "given this
function call, produce an indexable clause to apply to this index".
Your example suggests that we might sometimes want to produce more than
one indexable clause, which is an interesting point but not hard to
accommodate --- just have the function return a list rather than
necessarily a single clause.  The business with expand() seems like
something the transform function could easily deal with.

I'll try to sketch up a more concrete plan soon.

            regards, tom lane


pgsql-hackers by date:

Previous
From: Paul Ramsey
Date:
Subject: Re: Changing SQL Inlining Behaviour (or...?)
Next
From: Paul Martinez
Date:
Subject: Re: [PROPOSAL] ON DELETE SET NULL () for Foreign Key Constraints