Re: Make COPY format extendable: Extract COPY TO format implementations
От | Nathan Bossart |
---|---|
Тема | Re: Make COPY format extendable: Extract COPY TO format implementations |
Дата | |
Msg-id | 20231205182458.GC2757816@nathanxps13 обсуждение исходный текст |
Ответ на | Make COPY format extendable: Extract COPY TO format implementations (Sutou Kouhei <kou@clear-code.com>) |
Ответы |
Re: Make COPY format extendable: Extract COPY TO format implementations
|
Список | 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
В списке pgsql-hackers по дате отправления: