Thanks for making those updates . On 20 February 2018 at 19:33, Andrew Dunstan <andrew.duns...@2ndquadrant.com> wrote: > On Mon, Feb 19, 2018 at 1:18 PM, David Rowley > <david.row...@2ndquadrant.com> wrote: >> Since the attnum order in the missing values appears to be well >> defined in ascending order, you can also simplify the comparison logic >> in equalTupleDescs(). The inner-most nested loop shouldn't be >> required. > > Well, this comment in the existing code in equalTupleDescs() suggests > that in fact we can't rely on the attrdef items being in attnum order: > > /* > * We can't assume that the items are always read from the system > * catalogs in the same order; so use the adnum field to identify > * the matching item to compare. > */
On closer look, perhaps the reason that comment claims the order is not well defined is that the use of the index depends on the value of criticalRelcachesBuilt in the following: pg_attribute_scan = systable_beginscan(pg_attribute_desc, AttributeRelidNumIndexId, criticalRelcachesBuilt, NULL, 2, skey); Otherwise, I see no reason for them to be out of order, as if I grep for instances of "->missing = " I only see the place where the missing attr details are set in RelationBuildTupleDesc() and one other place in CreateTupleDescCopyConstr(), where it's simply just copied via memcpy(). Nevertheless, it would be interesting to see how much a bsearch in getmissingattr would help Tomas' case. Though, perhaps you're happy enough with the performance already. I'll make another pass over the updated code soon to see if I can see anything else. -- David Rowley http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Training & Services
