Re: Changing SQL Inlining Behaviour (or...?)

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: Changing SQL Inlining Behaviour (or...?)
Дата
Msg-id 29368.1547953418@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Re: Changing SQL Inlining Behaviour (or...?)  (Paul Ramsey <pramsey@cleverelephant.ca>)
Ответы Re: Changing SQL Inlining Behaviour (or...?)  (Tom Lane <tgl@sss.pgh.pa.us>)
Список 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 по дате отправления:

Предыдущее
От: Paul Ramsey
Дата:
Сообщение: Re: Changing SQL Inlining Behaviour (or...?)
Следующее
От: Paul Martinez
Дата:
Сообщение: Re: [PROPOSAL] ON DELETE SET NULL () for Foreign Key Constraints