Conversation
SteveLauC
force-pushed
the
feat/expression
branch
from
3b8e246 to
6761b61
Compare
|
This one's complex enough that I'd recommend preparing a design doc as a temporary part of the PR. |
Yeah, I agree, let me write a design doc for the implementation |
SteveLauC
force-pushed
the
feat/expression
branch
2 times, most recently
from
f0c085d to
99a4c95
Compare
SteveLauC
force-pushed
the
feat/expression
branch
2 times, most recently
from
1ce648f to
433ac69
Compare
|
Hi TJ @tjgreen42 , I’ve finished the design doc (see docs/expression_index.md). On the implementation side, everything is done except for the explicit index validation part, which needs us to merge #195 first. It would be great if you take a look at it and give some feedback when you get a chance. |
Index expressions stored in pg_index.indexprs always use varno = 1, since the indexed table has RT index 1 at CREATE INDEX time. However, when the same expression is evaluated in a query, the table’s RT index may differ (e.g., in multi-relation queries). This commit updates Var nodes in index expressions to use the table’s actual RT index in the query tree, ensuring correct evaluation.
Ensure expression index evaluation uses the correct scan tuple and restore buffer release during recovery.
SteveLauC
force-pushed
the
feat/expression
branch
from
2135af2 to
cfc46ae
Compare
Hi @SteveLauC, apologies for the radio silence, I missed this update! I can take a look later this week. Are you still interested in pushing this PR out? |
2 participants
Still WIP...