8000 Allow extensions to generate lossy index conditions. · postgrespro/postgres_cluster@74dfe58 · GitHub
[go: up one dir, main page]
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
  • doc/src/sgml
  • src
    • backend
      • optimizer
      • < 10000 div class="PRIVATE_TreeView-item-container prc-TreeView-TreeViewItemContainer--2Rkn" style="--level:3">
        utils/adt
  • include
  • test/regress

    • 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)
    0