database/postgres
1
0
Fork 0
mirror of https://github.com/postgres/postgres.git synced 2025-07-30 11:03:19 +03:00
Code Activity

Allow extensions to generate lossy index conditions.

Browse Source 
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
This commit is contained in:
Tom Lane
2019-02-11 21:26:08 -05:00
parent ea92368cd1
commit 74dfe58a59
20 changed files with 1770 additions and 1290 deletions
Download Patch File Download Diff File Expand all files Collapse all files

14
doc/src/sgml/xfunc.sgml
View File

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