From: | Sutou Kouhei <kou(at)clear-code(dot)com> |
---|---|
To: | zhjwpku(at)gmail(dot)com |
Cc: | michael(at)paquier(dot)xyz, sawada(dot)mshk(at)gmail(dot)com, andrew(at)dunslane(dot)net, nathandbossart(at)gmail(dot)com, pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: Make COPY format extendable: Extract COPY TO format implementations |
Date: | 2024-02-02 07:47:02 |
Message-ID: | 20240202.164702.1111161499168526271.kou@clear-code.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Hi,
In <CAEG8a3LxnBwNRPRwvmimDvOkPvYL8pB1+rhLBnxjeddFt3MeNw(at)mail(dot)gmail(dot)com>
"Re: Make COPY format extendable: Extract COPY TO format implementations" on Fri, 2 Feb 2024 15:27:15 +0800,
Junwang Zhao <zhjwpku(at)gmail(dot)com> wrote:
> I agree CopyToRoutine should be placed into CopyToStateData, but
> why set it after ProcessCopyOptions, the implementation of
> CopyToGetRoutine doesn't make sense if we want to support custom
> format in the future.
>
> Seems the refactor of v11 only considered performance but not
> *extendable copy format*.
Right.
We focus on performance for now. And then we will focus on
extendability. [1]
> If V7 and V10 have no performance reduction, then I think V6 is also
> good with performance, since most of the time goes to CopyToOneRow
> and CopyFromOneRow.
Don't worry. I'll re-submit changes in the v6 patch set
again after the current patch set that focuses on
performance is merged.
> I just think we should take the *extendable* into consideration at
> the beginning.
Introducing Copy{To,From}Routine is also valuable for
extendability. We can improve extendability later. Let's
focus on only performance for now to introduce
Copy{To,From}Routine.
Thanks,
--
kou
From | Date | Subject | |
---|---|---|---|
Next Message | Richard Guo | 2024-02-02 07:48:28 | Re: Commitfest 2024-01 is now closed |
Previous Message | Richard Guo | 2024-02-02 07:46:58 | Re: An improvement on parallel DISTINCT |