Re: Optimizing Node Files Support

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Ranier Vilela <ranier(dot)vf(at)gmail(dot)com>
Cc: vignesh C <vignesh21(at)gmail(dot)com>, John Naylor <john(dot)naylor(at)enterprisedb(dot)com>, Pg Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Optimizing Node Files Support
Date: 2023-01-06 15:18:03
Message-ID: 2962750.1673018283@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Ranier Vilela <ranier(dot)vf(at)gmail(dot)com> writes:
> Em qua., 4 de jan. de 2023 às 19:39, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Andrew Dunstan 2023-01-06 15:18:55 Re: [PATCH] Add `verify-system` sslmode to use system CA pool for server cert
Previous Message Tom Lane 2023-01-06 14:58:29 Re: Resolve UNKNOWN type to relevant type instead of text type while bulk update using values