Hi All,
I hope I am early enough for PG20, so v6 maintains the full scope.
0001 as the name suggests is just a benchmark, to get a baseline.
0002 is just a refactoring to ensure build_index_pathkeys is called once per index.
master is calling once to produce forward pathkeys and once to produce
backward pathkeys.
Other questions are: Should we maybe do this in a way to support monotonicity
for user defined functions too? Maybe use some per argument flags that can
retrieved without the call by oid?
v6 splits the pathkey monotonicity analysis in two parts.
If the pathkey expression depends on a single table, the innermost
sub expression that contains all variable terms is extracted during the index
creation, and stored in slope_info.
When considering indices for pathkeys, check if the index key matches
the slope info source of variation, if it does, check the monotonicity.
Limitations:
Not supporting pathkeys [f(x), x], maybe useful for
queries SELECT OVER (PARTITION f(x) ORDER BY x)
I have an implementation on a 0006 patch but I think it would hurt the overall
patchset quality.
Not working with joins where I expected a MergeJoin to be used.
Any hints here? Because I am not properly using equivalence classes? or something else?
I see that `make_canonical_pathkey` does a list search for every index key.
expressions, the complexity is roughly quadratic with the number of indices.
I suspect that pointer chasing having a preallocated array
would already be better, as it would probably improve the memory locality.
Would it be worth investigating other data structures here, like hash or a tree?
(I guess the answer will be no as that could hurt the very simple plans with
a handful of indices).
Regards,
Alexandre
