partitioning - changing a slot's descriptor is expensive - Mailing list pgsql-hackers

From Andres Freund
Subject partitioning - changing a slot's descriptor is expensive
Date
Msg-id 20180627050928.jeejsw5eub2ivilh@alap3.anarazel.de
Whole thread Raw
Responses Re: partitioning - changing a slot's descriptor is expensive
Re: partitioning - changing a slot's descriptor is expensive
List pgsql-hackers
Hi,

(sorry if I CCed the wrong folks, the code has changed a fair bit)

I noticed that several places in the partitioning code look like:

    /*
     * If the tuple has been routed, it's been converted to the
     * partition's rowtype, which might differ from the root
     * table's.  We must convert it back to the root table's
     * rowtype so that val_desc shown error message matches the
     * input tuple.
     */
    if (resultRelInfo->ri_PartitionRoot)
    {
        TableTuple tuple = ExecFetchSlotTuple(slot);
        TupleConversionMap *map;

        rel = resultRelInfo->ri_PartitionRoot;
        tupdesc = RelationGetDescr(rel);
        /* a reverse map */
        map = convert_tuples_by_name(orig_tupdesc, tupdesc,
                                     gettext_noop("could not convert row type"));
        if (map != NULL)
        {
            tuple = do_convert_tuple(tuple, map);
            ExecSetSlotDescriptor(slot, tupdesc);
            ExecStoreTuple(tuple, slot, InvalidBuffer, false);
        }
    }


Unfortunately calling ExecSetSlotDescriptor() is far from cheap, it has
to reallocate the values/isnull arrays (and potentially do desc pinning
etc). Nor is it always cheap to call ExecFetchSlotTuple(slot) - it might
be a virtual slot. Calling heap_deform_tuple(), as done in
do_convert_tuple(), might be superfluous work, because the input tuple
might already be entirely deformed in the input slot.

I think it'd be good to rewrite the code so there's an input and an
output slot that each will keep their slot descriptors set.

Besides performance as the code stands, this'll also be important for
pluggable storage (as we'd otherwise get a *lot* of back/forth
conversions between tuple formats).

Anybody interesting in writing a patch that redoes this?

Greetings,

Andres Freund


pgsql-hackers by date:

Previous
From: "Chen, Yan-Jack (NSB - CN/Hangzhou)"
Date:
Subject: RE: "wal receiver" process hang in syslog() while exiting afterreceiving SIGTERM while the postgres has been promoted.
Next
From: Rushabh Lathia
Date:
Subject: Typo in llvm_function_reference