No sooner had I committed e2c2c2e8b1df7dfdb01e7e6f6191a569ce3c3195 than
I started having second thoughts about the choice of representation.
The requirement is to tell which index column each potential index qual
is meant to be used with. I used a list-of-sublists representation, in
which each sublist corresponds to an index column, because that's what
group_clauses_by_indexkey has historically produced. But on reflection
that seems like a leftover Lisp hack more than it does a natural choice.
The alternative that comes to mind is to use a flat list of quals and a
parallel integer list of column numbers. Places that need to track what
goes with what would chase both lists in parallel using forboth(), while
places that don't care could just ignore the integer list.
This would end up with a net savings of palloc overhead because we could
get rid of the assorted calls to flatten_clausegroups_list and
flatten_indexorderbys_list that are currently needed by code that
doesn't want to think about column correspondences. And it just seems
a bit more natural.
The only downside I can think of is that amcostestimate functions would
need two more arguments, bringing us to the point where we need an
OidFunctionCall11 (!), or else do some more drastic restructuring like
passing them an IndexPath explicitly. But the existing commit has
already effectively changed their API, so this doesn't seem like a
showstopper.
Thoughts either way?
regards, tom lane
