Thread: Representation of index clause lists
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
On Fri, Dec 23, 2011 at 7:53 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote: > Thoughts either way? OidFunctionCall11? How about making a struct out of some or all of those arguments and passing that? What about using arrays rather than Lists? -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company
Robert Haas <robertmhaas@gmail.com> writes:
> On Fri, Dec 23, 2011 at 7:53 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
>> Thoughts either way?
> OidFunctionCall11? How about making a struct out of some or all of
> those arguments and passing that?
Well, that was what I meant by the allusion to IndexPath --- I'm
inclined to pass "root" and "indexpath" as the only input arguments,
with the other inputs being found in the path struct. (Hm, maybe
"outer_rel" would have to remain separate too.) I guess we could
also think about merging the four output parameters into one output
struct, but I'm less excited about that since it would involve inventing
a struct that's not used otherwise.
> What about using arrays rather than Lists?
I think lists are more convenient to work with and iterate over, as long
as you only need iteration and not random access, which is the case here
AFAICS. In particular, if we changed to arrays then we'd have to
reinvent assorted operations like list_union that are currently used on
these lists, and I don't see any bang for the buck there.
regards, tom lane