On Thu, 2 May 2024 at 18:50, Chris Cleveland <ccleveland@dieselpoint.com> wrote:
>
> Sorry to have to ask for help here, but no amount of stepping through code is giving me the answer.
>
> I'm building an index access method which supports an ordering operator:
[...]
> so there's no reason the system needs to know the actual float value returned by rank_match(), the ordering operator
distancefunction. In any case, that value can only be calculated based on information in the index itself, and can't be
calculatedby rank_match().
>
> Nevertheless, the system calls rank_match() after every call to amgettuple(), and I can't figure out why. I've
steppedthrough the code, and it looks like it has something to do with ScanState.ps.ps.ps_ProjInfo, but I can't figure
outwhere or why it's getting set.
>
> Here's a sample query. I have not found a query that does *not* call rank_match():
[...]
> I'd be grateful for any help or insights.
The ordering clause produces a junk column that's used to keep track
of the ordering, and because it's a projected column (not the indexed
value, but an expression over that column) the executor will execute
that projection. This happens regardless of it's use in downstream
nodes due to planner or executor limitations.
See also Heikki's thread over at [0], and a comment of me about the
same issue over at pgvector's issue board at [1].
Kind regards,
Matthias van de Meent
Neon (https://neon.tech)
[0] https://www.postgresql.org/message-id/2ca5865b-4693-40e5-8f78-f3b45d5378fb%40iki.fi
[1] https://github.com/pgvector/pgvector/issues/359#issuecomment-1840786021
