Tom Lane wrote:
> Alvaro Herrera <alvherre@2ndquadrant.com> writes:
> > Tom Lane wrote:
> >> Hmm. The bespoke code for constructing the attno map bothers me;
> >> surely there is existing code that does that? If not, it'd still
> >> make more sense to factor it out, I think, because there will be
> >> other needs for it in future.
>
> > There isn't any that I could find -- all the existing callers of
> > map_variable_attnos build their map in other ways (while walking an
> > attribute array at construction time).
>
> [ pokes around... ] The code I was thinking of is convert_tuples_by_name
> in access/common/tupconvert.c. There's a bit of an API mismatch in that
> it wants to wrap the mapping array in a TupleConversionMap struct; but
> maybe we could refactor tupconvert.c to offer a way to get just the map
> array.
Ah, nice gadget. I think the attached patch should do.
> > I also modified the algorithm to use the relcache instead of walking the
> > child's attribute list for each parent attribute (that was silly).
>
> Hmm. That might be better in a big-O sense but I doubt it's faster for
> reasonable numbers of columns.
Hm, I was thinking in unreasonable numbers of columns, keeping in mind
that they can appear in arbitrary order in child tables. Then again,
that probably seldom occurs in real databases. I suppose this could
become an issue with table partitioning becoming more common, but I'm
okay with deferring the optimization work.
--
Álvaro Herrera https://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers