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 -- Sent via pgsql-hackers mailing list (firstname.lastname@example.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers