On Fri, Feb 09, 2024 at 04:32:05PM +0900, Sutou Kouhei wrote: > In <zcwotr1n0gelf...@paquier.xyz> > "Re: Make COPY format extendable: Extract COPY TO format implementations" > on Fri, 9 Feb 2024 13:21:34 +0900, > Michael Paquier <mich...@paquier.xyz> wrote: >> A next step I think we could take is to split the binary-only and the >> text/csv-only data in each cstate into their own structure to make the >> structure, with an opaque pointer that custom formats could use, but a >> lot of fields are shared as well. > > It'll make COPY code base cleaner but it may decrease > performance.
Perhaps, but I'm not sure, TBH. But perhaps others can comment on
this point. This surely needs to be studied closely.
> My suggestion:
> 1. Introduce Copy{To,From}Routine
> (We can do it based on the v14 patch.)
> 2. Add an opaque pointer to Copy{To,From}Routine
> (This must not have performance impact.)
> 3.a. Split format specific data to the opaque space
> 3.b. Add support for registering custom format handler by
> creating a function
> 4. ...
4. is going to need 3. At this point 3.b sounds like the main thing
to tackle first if we want to get something usable for the end-user
into this release, at least. Still 2 is important for pluggability
as we pass the cstates across all the routines and custom formats want
to save their own data, so this split sounds OK. I am not sure how
much of 3.a we really need to do for the in-core formats.
> I think that we should not use this approach for
> performance. We need to use "static inline" and constant
> argument instead something like the attached
> remove-copy-read-attributes.diff.
FWIW, using inlining did not show any performance change here.
Perhaps that's only because this is called in the COPY FROM path once
per row (even for the case of using 1 attribute with blackhole_am).
--
Michael
signature.asc
Description: PGP signature
