From: | David Rowley <dgrowleyml(at)gmail(dot)com> |
---|---|
To: | Andres Freund <andres(at)anarazel(dot)de> |
Cc: | Heikki Linnakangas <hlinnaka(at)iki(dot)fi>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>, vignesh C <vignesh21(at)gmail(dot)com> |
Subject: | Re: Split copy.c |
Date: | 2020-11-03 02:15:27 |
Message-ID: | CAApHDvo=VDA_y6vFaRUR_JHUcNQ2VHarosqW0LKqhA2JzKOafw@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Tue, 3 Nov 2020 at 07:35, Andres Freund <andres(at)anarazel(dot)de> wrote:
>
> On 2020-11-02 19:43:38 +0200, Heikki Linnakangas wrote:
> > On 02/11/2020 19:23, Andres Freund wrote:
> > > On 2020-11-02 11:03:29 +0200, Heikki Linnakangas wrote:
> > > > There isn't much common code between COPY FROM and COPY TO, so I propose
> > > > that we split copy.c into two: copyfrom.c and copyto.c. See attached. I thin
> > > > that's much nicer.
> > >
> > > Not quite convinced that's the right split - or perhaps there's just
> > > more potential. My feeling is that splitting out all the DML related
> > > code would make the code considerably easier to read.
> >
> > What do you mean by DML related code?
>
> Basically all the insertion related code (e.g CopyMultiInsert*, lots of
> code in CopyFrom()) and perhaps also the type input invocations.
I quite like the fact that those are static and inline-able. I very
much imagine there'd be a performance hit if we moved them out to
another .c file and made them extern. Some of those functions can be
quite hot when copying into a partitioned table.
David
From | Date | Subject | |
---|---|---|---|
Next Message | Tomas Vondra | 2020-11-03 02:37:43 | Re: enable_incremental_sort changes query behavior |
Previous Message | Hou, Zhijie | 2020-11-03 01:39:17 | Fix typo in xlogreader.h and procarray.c |