From: | Nathan Bossart <nathandbossart(at)gmail(dot)com> |
---|---|
To: | Sutou Kouhei <kou(at)clear-code(dot)com> |
Cc: | pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: Make COPY format extendable: Extract COPY TO format implementations |
Date: | 2023-12-05 18:24:58 |
Message-ID: | 20231205182458.GC2757816@nathanxps13 |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
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
From | Date | Subject | |
---|---|---|---|
Next Message | Nathan Bossart | 2023-12-05 18:28:45 | Re: backtrace_on_internal_error |
Previous Message | Robert Haas | 2023-12-05 18:16:22 | Re: backtrace_on_internal_error |