Skip to content

Commit 74dfe58

Browse files
tglsfdctglsfdc
committed
Allow extensions to generate lossy index conditions.
For a long time, indxpath.c has had the ability to extract derived (lossy) index conditions from certain operators such as LIKE. For just as long, it's been obvious that we really ought to make that capability available to extensions. This commit finally accomplishes that, by adding another API for planner support functions that lets them create derived index conditions for their functions. As proof of concept, the hardwired "special index operator" code formerly present in indxpath.c is pushed out to planner support functions attached to LIKE and other relevant operators. A weak spot in this design is that an extension needs to know OIDs for the operators, datatypes, and opfamilies involved in the transformation it wants to make. The core-code prototypes use hard-wired OID references but extensions don't have that option for their own operators etc. It's usually possible to look up the required info, but that may be slow and inconvenient. However, improving that situation is a separate task. I want to do some additional refactorization around selfuncs.c, but that also seems like a separate task. Discussion: https://postgr.es/m/15193.1548028093@sss.pgh.pa.us
1 parent ea92368 commit 74dfe58

File tree

20 files changed

+1771
-1291
lines changed

20 files changed

+1771
-1291
lines changed

‎doc/src/sgml/xfunc.sgml

+14
Original file line numberDiff line numberDiff line change
@@ -3460,4 +3460,18 @@ supportfn(internal) returns internal
34603460
This can be done by a support function that implements
34613461
the <literal>SupportRequestRows</literal> request type.
34623462
</para>
3463+
3464+
<para>
3465+
For target functions that return boolean, it may be possible to
3466+
convert a function call appearing in WHERE into an indexable operator
3467+
clause or clauses. The converted clauses might be exactly equivalent
3468+
to the function's condition, or they could be somewhat weaker (that is,
3469+
they might accept some values that the function condition does not).
3470+
In the latter case the index condition is said to
3471+
be <firstterm>lossy</firstterm>; it can still be used to scan an index,
3472+
but the function call will have to be executed for each row returned by
3473+
the index to see if it really passes the WHERE condition or not.
3474+
To create such conditions, the support function must implement
3475+
the <literal>SupportRequestIndexCondition</literal> request type.
3476+
</para>
34633477
</sect1>

0 commit comments

Comments
 (0)