On Thu, 2 May 2024 at 18:50, Chris Cleveland <cclevel...@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 distance function. In any case, that > value can only be calculated based on information in the index itself, and > can't be calculated by rank_match(). > > Nevertheless, the system calls rank_match() after every call to amgettuple(), > and I can't figure out why. I've stepped through the code, and it looks like > it has something to do with ScanState.ps.ps.ps_ProjInfo, but I can't figure > out where 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
