Date: Tue, 5 Dec 2023 12:24:58 -0600
From: Nathan Bossart <nathandbossart@gmail.com>
To: Sutou Kouhei <kou@clear-code.com>
Cc: pgsql-hackers@postgresql.org
Subject: Re: Make COPY format extendable: Extract COPY TO format
 implementations
Message-ID: <20231205182458.GC2757816@nathanxps13>
References: <20231204.153548.2126325458835528809.kou@clear-code.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20231204.153548.2126325458835528809.kou@clear-code.com>
Archived-At: 
 <https://www.postgresql.org/message-id/20231205182458.GC2757816%40nathanxps13>
Precedence: bulk

On Mon, Dec 04, 2023 at 03:35:48PM +0900, Sutou Kouhei wrote:
> I want to work on making COPY format extendable. I attach
> the first patch for it. I'll send more patches after this is
> merged.

Given the current discussion about adding JSON, I think this could be a
nice bit of refactoring that could ultimately open the door to providing
other COPY formats via shared libraries.

> In other words, this is just a refactoring for further
> changes to make COPY format extendable. If I use "complete
> the task and then request reviews for it" approach, it will
> be difficult to review because changes for it will be
> large. So I want to work on this step by step. Is it
> acceptable?

I think it makes sense to do this part independently, but we should be
careful to design this with the follow-up tasks in mind.

> So I measured COPY TO time with/without this change. You can
> see there is no significant loss of performance.
> 
> Data: Random 32 bit integers:
> 
>     CREATE TABLE data (int32 integer);
>     INSERT INTO data
>       SELECT random() * 10000
>         FROM generate_series(1, ${n_records});

Seems encouraging.  I assume the performance concerns stem from the use of
function pointers.  Or was there something else?

-- 
Nathan Bossart
Amazon Web Services: https://aws.amazon.com