Re: Optimizing Node Files Support - Mailing list pgsql-hackers

From Tom Lane
Subject Re: Optimizing Node Files Support
Date
Msg-id 2962750.1673018283@sss.pgh.pa.us
Whole thread Raw
In response to Re: Optimizing Node Files Support  (Ranier Vilela <ranier.vf@gmail.com>)
Responses Re: Optimizing Node Files Support  ("Gregory Stark (as CFM)" <stark.cfm@gmail.com>)
List pgsql-hackers
Ranier Vilela <ranier.vf@gmail.com> writes:
> Em qua., 4 de jan. de 2023 às 19:39, Tom Lane <tgl@sss.pgh.pa.us> escreveu:
>> Yeah.  The way that I'd been thinking of optimizing the copy functions
>> was more or less as attached: continue to write all the COPY_SCALAR_FIELD
>> macro calls, but just make them expand to no-ops after an initial memcpy
>> of the whole node.

> I think this option is worse.
> By disabling these macros, you lose their use in other areas.

What other areas?  They're local to copyfuncs.c.

The bigger picture here is that as long as we have any manually-maintained
node copy functions, it seems best to adhere to the existing convention
of explicitly listing each and every field in them.  I'm far more
concerned about errors-of-omission than I am about incremental performance
gains (which still haven't been demonstrated to exist, anyway).

> v3 attached.

I think you're wasting people's time if you don't provide some
performance measurements showing that this is worth doing from
a speed standpoint.

            regards, tom lane



pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: Resolve iso-8859-1 type to relevant type instead of text type while bulk update using values
Next
From: Andrew Dunstan
Date:
Subject: Re: [PATCH] Add `verify-system` sslmode to use system CA pool for server cert