Movatterモバイル変換


[0]ホーム

URL:


Skip to content

Navigation Menu

Sign in
Appearance settings

Search code, repositories, users, issues, pull requests...

Provide feedback

We read every piece of feedback, and take your input very seriously.

Saved searches

Use saved searches to filter your results more quickly

Sign up
Appearance settings

Commit74dfe58

Browse files
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 availableto extensions. This commit finally accomplishes that, by adding anotherAPI for planner support functions that lets them create derived indexconditions for their functions. As proof of concept, the hardwired"special index operator" code formerly present in indxpath.c is pushedout to planner support functions attached to LIKE and other relevantoperators.A weak spot in this design is that an extension needs to know OIDs forthe operators, datatypes, and opfamilies involved in the transformationit wants to make. The core-code prototypes use hard-wired OID referencesbut extensions don't have that option for their own operators etc. It'susually possible to look up the required info, but that may be slow andinconvenient. However, improving that situation is a separate task.I want to do some additional refactorization around selfuncs.c, butthat also seems like a separate task.Discussion:https://postgr.es/m/15193.1548028093@sss.pgh.pa.us
1 parentea92368 commit74dfe58

File tree

20 files changed

+1771
-1291
lines changed

20 files changed

+1771
-1291
lines changed

‎doc/src/sgml/xfunc.sgml

Lines changed: 14 additions & 0 deletions
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)

[8]ページ先頭

©2009-2025 Movatter.jp