Hi Andrei, On Fri, Jan 24, 2025 at 1:23 AM Andrei Lepikhov <lepi...@gmail.com> wrote:
> I may not be close to the task monitoring area, but I utilise queryId > and other tools to differ plan nodes inside extensions. Initially, like > queryId serves as a class identifier for queries, plan_id identifies a > class of nodes, not a single node. In the implementation provided here, > nodes with the same hash can represent different subtrees. For example, > JOIN(A, JOIN(B,C)) and JOIN(JOIN(B,C),A) may have the same ID. > > Moreover, I wonder if this version of plan_id reacts to the join level > change. It appears that only a change of the join clause alters the > plan_id hash value, which means you would end up with a single hash for > very different plan nodes. Is that acceptable? To address this, we > should consider the hashes of the left and right subtrees and the hashes > of each subplan (especially in the case of Append). > I looked back at this again just to confirm we're not missing anything: I don't think any of the posted patch versions (including the just shared v4) have a problem with distinguishing two plans that are very similar but only differ in JOIN order. Since we descend into the inner/outer plans via the setrefs.c treewalk, the placement of JOIN nodes vs other nodes should cause a different plan jumble (and we include both the node tag for the join/scan nodes, as well as the RT index the scans point to in the jumble). Do you have a reproducer that shows these two generate the same plan ID? Thanks, Lukas -- Lukas Fittl
