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
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 |