Re: Allowing extensions to supply operator-/function-specific info
Tom Lane <tgl@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>
To: Paul Ramsey <pramsey@cleverelephant.ca>
Cc: PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>
Date: 2019-02-26T22:19:01Z
Lists: pgsql-hackers
Commits
Same data as JSON:
GET /api/v1/messages/:b64id/commits
the thread's linked commits as JSON, with link sources.
API reference →
-
Allow extensions to generate lossy index conditions.
- 74dfe58a5927 12.0 landed
-
Build out the planner support function infrastructure.
- a391ff3c3d41 12.0 landed
-
Create the infrastructure for planner support functions.
- 1fb57af92069 12.0 landed
-
Disable transforms that replaced AT TIME ZONE with RelabelType.
- c22ecc6562aa 10.0 cited
Paul Ramsey <pramsey@cleverelephant.ca> writes: > New line of questioning: under what conditions will the support > function be called in a T_SupportRequestIndexCondition mode? It'll be called if the target function appears at top level of a WHERE or JOIN condition and any one of the function's arguments syntactically matches some column of an index. If there's multiple arguments matching the same index column, say index on "x" and we have "f(z, x, x)", you'll get one call and it will tell you about the first match (req->indexarg == 1 in this example). Sorting out what to do in such a case is your responsibility. If there's arguments matching more than one index column, say index declared on (x, y) and we have "f(x, y)", you'll get a separate call for each index column. Again, sorting out what to do for each one is your responsibility. In most cases, multiple matching arguments are going to lead to failure to construct any useful index condition, because your comparison value has to be a pseudoconstant (ie, not a variable from the same table, so in both of the above examples there's no function argument you could compare to). But we don't prejudge that, because it's possible that a function with 3 or more arguments could produce something useful anyway. For instance, if what we've got is "f(x, y, constant)" then it's possible that the semantics of the function are such that y can be ignored and we can make something indexable like "x && constant". All this is the support function's job to know. > I have > created a table (foo) a geometry column (g) and an index (GIST on > foo(g)) and am running a query against foo using a noop function with > a support function bound to it. > The support function is called, twice, once in > T_SupportRequestSimplify mode and once in T_SupportRequestCost mode. What's the query look like exactly? The other two calls will occur anyway, but SupportRequestIndexCondition depends on the function call's placement. regards, tom lane