In <20240320.232732.488684985873786799@clear-code.com>
"Re: Make COPY format extendable: Extract COPY TO format implementations" on
Wed, 20 Mar 2024 23:27:32 +0900 (JST),
Sutou Kouhei wrote:
> Hi,
>
> Could someone review the v17 patch to proceed this?
>
> The v17 patch:
> https://
%40paquier.xyz#eccfd1a0131af93c48026d691cc247f4
Thanks,
--
kou
In <20240308.092254.359611633589181574@clear-code.com>
"Re: Make COPY format extendable: Extract COPY TO format implementations" on
Fri, 08 Mar 2024 09:22:54 +0900 (JST),
Sutou Kouhei wrote:
> Hi,
>
&g
Hi,
In
"Re: Make COPY format extendable: Extract COPY TO format implementations" on
Wed, 13 Mar 2024 16:00:46 +0800,
jian he wrote:
>> More use cases will help us which callbacks are needed. We
>> will be able to collect more use cases by providing basic
>
On Mon, Mar 11, 2024 at 8:56 AM Sutou Kouhei wrote:
>
> Hi,
>
> In
> "Re: Make COPY format extendable: Extract COPY TO format implementations"
> on Mon, 11 Mar 2024 08:00:00 +0800,
> jian he wrote:
>
> > Hi, here are my cents:
> > Currently in
Hi,
In
"Re: Make COPY format extendable: Extract COPY TO format implementations" on
Mon, 11 Mar 2024 08:00:00 +0800,
jian he wrote:
> Hi, here are my cents:
> Currently in v17, we have 3 extra functions within DoCopyTo
> CopyToStart, one time, start, doing so
On Fri, Mar 8, 2024 at 8:23 AM Sutou Kouhei wrote:
>
>
> This shows that the v17 approach doesn't affect the current
> text/csv/binary implementations. (The v17 approach just adds
> 2 new structs, Copy{From,To}Rountine, without changing the
> current text/csv/binary implementations.)
>
> Can we
Hi,
In
"Re: Make COPY format extendable: Extract COPY TO format implementations" on
Thu, 7 Mar 2024 15:32:01 +0900,
Michael Paquier wrote:
> While on it, here are some profiles based on HEAD and v17 with the
> previous tests (COPY TO /dev/null, COPY FROM data
On Wed, Mar 06, 2024 at 03:34:04PM +0900, Michael Paquier wrote:
> I am not sure that my schedule is on track to allow that for this
> release, unfortunately, especially with all the other items to review
> and discuss to make this thread feature-complete. There should be
> a bit more than four
On Tue, Mar 05, 2024 at 05:18:08PM +0900, Sutou Kouhei wrote:
> I'll send the following patches after this patch is
> merged.
I am not sure that my schedule is on track to allow that for this
release, unfortunately, especially with all the other items to review
and discuss to make this thread
Hi,
In
"Re: Make COPY format extendable: Extract COPY TO format implementations" on
Tue, 5 Mar 2024 15:16:33 +0900,
Michael Paquier wrote:
> CopyOneRowTo() could do something like that to avoid the extra
> indentation:
> if (cstate->routine)
> {
> cstate-&
On Mon, Mar 04, 2024 at 02:11:08PM +0900, Sutou Kouhei wrote:
> If this is a blocker of making COPY format extendable, can
> we defer moving the existing text/csv/binary format
> implementations to Copy{From,To}Routine for now as Michael
> suggested to proceed making COPY format extendable? (Can
Hi,
In <20240301.154443.618034282613922707@clear-code.com>
"Re: Make COPY format extendable: Extract COPY TO format implementations" on
Fri, 01 Mar 2024 15:44:43 +0900 (JST),
Sutou Kouhei wrote:
>> I guess so. It does not make much of a differen
Hi,
In
"Re: Make COPY format extendable: Extract COPY TO format implementations" on
Fri, 1 Mar 2024 14:31:38 +0900,
Michael Paquier wrote:
> I guess so. It does not make much of a difference, though. The thing
> is that the dispatch caused by the custom callbacks calle
Hi,
In <20240222.183948.518018047578925034@clear-code.com>
"Re: Make COPY format extendable: Extract COPY TO format implementations" on
Thu, 22 Feb 2024 18:39:48 +0900 (JST),
Sutou Kouhei wrote:
> How about adding "is_csv" to CopyReadline() and
>
On Thu, Feb 22, 2024 at 06:39:48PM +0900, Sutou Kouhei wrote:
> If so, adding the change independently on HEAD makes
> sense. But I don't know why that improves
> performance... Inlining?
I guess so. It does not make much of a difference, though. The thing
is that the dispatch caused by the
Hi,
In
"Re: Make COPY format extendable: Extract COPY TO format implementations" on
Thu, 22 Feb 2024 15:44:16 +0900,
Michael Paquier wrote:
> I was comparing what you have here, and what's been attached by Andres
> at [1] and the top of the changes on my development bra
On Thu, Feb 15, 2024 at 03:34:21PM +0900, Sutou Kouhei wrote:
> It seems that it improves performance a bit but my
> environment isn't suitable for benchmark. So they may not
> be valid numbers.
I was comparing what you have here, and what's been attached by Andres
at [1] and the top of the
Hi,
In
"Re: Make COPY format extendable: Extract COPY TO format implementations" on
Thu, 15 Feb 2024 17:09:20 +0800,
jian he wrote:
> My environment is slow (around 10x) but consistent.
> I see around 2-3 percent increase consistently.
> (with patch 7369.068 ms, withou
On Thu, Feb 15, 2024 at 2:34 PM Sutou Kouhei wrote:
>
>
> Thanks for the info. Let's use InputFunctionCallSafeWithInfo().
> See that attached patch:
> v2-0001-Reuse-fcinfo-used-in-COPY-FROM.patch
>
> I also attach a patch for COPY TO:
> v1-0001-Reuse-fcinfo-used-in-COPY-TO.patch
>
> I measured
Hi,
In <20240213.173340.1518143507526518973@clear-code.com>
"Re: Make COPY format extendable: Extract COPY TO format implementations" on
Tue, 13 Feb 2024 17:33:40 +0900 (JST),
Sutou Kouhei wrote:
> I'll reply other comments later...
I've read other comments and
Hi,
In
"Re: Make COPY format extendable: Extract COPY TO format implementations" on
Wed, 14 Feb 2024 15:52:36 +0900,
Michael Paquier wrote:
>> How about InputFunctionCallSafeWithInfo(),
>> InputFunctionCallSafeInfo() or
>> InputFunctionCallInfoCallS
On Wed, Feb 14, 2024 at 02:08:51PM +0900, Sutou Kouhei wrote:
> I understand the feeling. SQL uses "prepared" for "prepared
> statement". There are similar function names such as
> InputFunctionCall()/InputFunctionCallSafe()/DirectInputFunctionCallSafe().
> They
> execute (call) an input function
Hi,
In
"Re: Make COPY format extendable: Extract COPY TO format implementations" on
Wed, 14 Feb 2024 12:28:38 +0900,
Michael Paquier wrote:
>> How about the attached patch approach? If it's a desired
>> approach, I can also write a separated patch for COPY TO.
>
On Tue, Feb 13, 2024 at 05:33:40PM +0900, Sutou Kouhei wrote:
> Hi,
>
> In <20240209192705.5qdilvviq3py2...@awork3.anarazel.de>
> "Re: Make COPY format extendable: Extract COPY TO format implementations"
> on Fri, 9 Feb 2024 11:27:05 -0800,
> Andres
Hi,
In <20240209192705.5qdilvviq3py2...@awork3.anarazel.de>
"Re: Make COPY format extendable: Extract COPY TO format implementations" on
Fri, 9 Feb 2024 11:27:05 -0800,
Andres Freund wrote:
>> +static void
>> +CopyFromTextInFunc(CopyFr
On Fri, Feb 09, 2024 at 11:27:05AM -0800, Andres Freund wrote:
> On 2024-02-09 13:21:34 +0900, Michael Paquier wrote:
>> +static void
>> +CopyFromTextInFunc(CopyFromState cstate, Oid atttypid,
>> + FmgrInfo *finfo, Oid *typioparam)
>> +{
>> +Oid
Hi,
On 2024-02-09 13:21:34 +0900, Michael Paquier wrote:
> +static void
> +CopyFromTextInFunc(CopyFromState cstate, Oid atttypid,
> +FmgrInfo *finfo, Oid *typioparam)
> +{
> + Oid func_oid;
> +
> + getTypeInputInfo(atttypid, _oid,
On Fri, Feb 09, 2024 at 04:32:05PM +0900, Sutou Kouhei wrote:
> In
> "Re: Make COPY format extendable: Extract COPY TO format implementations"
> on Fri, 9 Feb 2024 13:21:34 +0900,
> Michael Paquier wrote:
>> A next step I think we could take is to split the bin
Hi,
In
"Re: Make COPY format extendable: Extract COPY TO format implementations" on
Fri, 9 Feb 2024 13:21:34 +0900,
Michael Paquier wrote:
>> - Revisit what we have here, looking at more profiles to see how HEAD
>> an v13 compare. It looks like we are on a good
On Fri, Feb 09, 2024 at 01:19:50PM +0900, Sutou Kouhei wrote:
> Are you already working on this? Do you want me to write the
> next patch based on the current master?
No need for a new patch, thanks. I've spent some time today doing a
rebase and measuring the whole, without seeing a degradation
On Wed, Feb 07, 2024 at 01:33:18PM +0900, Michael Paquier wrote:
> Hmm. That explains why I was not seeing any differences with this
> callback then. It seems to me that the order of actions to take is
> clear, like:
> - Revert 2889fd23be56 to keep a clean state of the tree, now done with
>
Hi,
In
"Re: Make COPY format extendable: Extract COPY TO format implementations" on
Wed, 7 Feb 2024 13:33:18 +0900,
Michael Paquier wrote:
> Hmm. That explains why I was not seeing any differences with this
> callback then. It seems to me that the order of actions to
On Thu, Feb 01, 2024 at 10:57:58AM +0900, Michael Paquier wrote:
> CREATE EXTENSION blackhole_am;
One thing I have forgotten here is to provide a copy of this AM for
future references, so here you go with a blackhole_am.tar.gz attached.
--
Michael
blackhole_am.tar.gz
Description:
On Tue, Feb 06, 2024 at 03:33:36PM -0800, Andres Freund wrote:
> Well, you can't just do that, because there's only one caller, namely
> CopyToTextOneRow(). What I am trying to suggest is something like the
> attached, just a quick hacky POC. Namely to split out CSV support from
>
Hi,
On 2024-02-06 15:11:05 +0900, Michael Paquier wrote:
> On Mon, Feb 05, 2024 at 09:46:42PM -0800, Andres Freund wrote:
> > No - what I mean is that it doesn't make sense to have copy_attribute_out(),
> > as e.g. CopyToTextOneRow() already knows that it's dealing with text, so it
> > can
On Mon, Feb 05, 2024 at 09:46:42PM -0800, Andres Freund wrote:
> No - what I mean is that it doesn't make sense to have copy_attribute_out(),
> as e.g. CopyToTextOneRow() already knows that it's dealing with text, so it
> can directly call the right function. That does require splitting a bit more
Hi,
On 2024-02-06 11:41:06 +0900, Michael Paquier wrote:
> On Mon, Feb 05, 2024 at 05:41:25PM -0800, Andres Freund wrote:
> > On 2024-02-06 10:01:36 +0900, Michael Paquier wrote:
> >> If you have concerns about that, I'm OK to revert, I'm not wedded to
> >> this level of control. Note that I've
On Mon, Feb 05, 2024 at 05:41:25PM -0800, Andres Freund wrote:
> On 2024-02-06 10:01:36 +0900, Michael Paquier wrote:
>> If you have concerns about that, I'm OK to revert, I'm not wedded to
>> this level of control. Note that I've actually seen *better*
>> runtimes.
>
> I'm somewhat worried that
Hi,
On 2024-02-06 10:01:36 +0900, Michael Paquier wrote:
> On Mon, Feb 05, 2024 at 10:21:18AM -0800, Andres Freund wrote:
> > Have you benchmarked the performance effects of 2889fd23be5 ? I'd not at all
> > be surprised if it lead to a measurable performance regression.
>
> Yes, I was looking at
On Mon, Feb 05, 2024 at 10:21:18AM -0800, Andres Freund wrote:
> Have you benchmarked the performance effects of 2889fd23be5 ? I'd not at all
> be surprised if it lead to a measurable performance regression.
Yes, I was looking at runtimes and some profiles around CopyOneRowTo()
to see the effects
On Mon, Feb 05, 2024 at 06:05:15PM +0900, Sutou Kouhei wrote:
> In
> "Re: Make COPY format extendable: Extract COPY TO format implementations"
> on Mon, 5 Feb 2024 16:14:08 +0900,
> Michael Paquier wrote:
>> 2) I have backpedaled on the postpare callback,
Hi,
Have you benchmarked the performance effects of 2889fd23be5 ? I'd not at all
be surprised if it lead to a measurable performance regression.
I think callbacks for individual attributes is the wrong approach - the
dispatch needs to happen at a higher level, otherwise there are too many
Hi,
In
"Re: Make COPY format extendable: Extract COPY TO format implementations" on
Mon, 5 Feb 2024 16:14:08 +0900,
Michael Paquier wrote:
> So, I've looked at all that today, and finished by applying two
> patches as of 2889fd23be56 and 95fb5b49024a to get some of
On Fri, Feb 02, 2024 at 05:46:18PM +0900, Sutou Kouhei wrote:
> Hi,
>
> In
> "Re: Make COPY format extendable: Extract COPY TO format implementations"
> on Fri, 2 Feb 2024 17:04:28 +0900,
> Michael Paquier wrote:
>
> > One idea I was considering is
Hi,
In
"Re: Make COPY format extendable: Extract COPY TO format implementations" on
Fri, 2 Feb 2024 17:04:28 +0900,
Michael Paquier wrote:
> One idea I was considering is whether we should use a special value in
> the "format" DefElem, say "custom:$m
On Fri, Feb 02, 2024 at 04:33:19PM +0900, Sutou Kouhei wrote:
> Hi,
>
> In
> "Re: Make COPY format extendable: Extract COPY TO format implementations"
> on Fri, 2 Feb 2024 15:21:31 +0900,
> Michael Paquier wrote:
>
> > I have done a review of v10
Hi,
In
"Re: Make COPY format extendable: Extract COPY TO format implementations" on
Fri, 2 Feb 2024 15:27:15 +0800,
Junwang Zhao wrote:
> I agree CopyToRoutine should be placed into CopyToStateData, but
> why set it after ProcessCopyOptions, the implementation of
&g
Hi,
In
"Re: Make COPY format extendable: Extract COPY TO format implementations" on
Fri, 2 Feb 2024 15:21:31 +0900,
Michael Paquier wrote:
> I have done a review of v10, see v11 attached which is still WIP, with
> the patches for COPY TO and COPY FROM merged together
On Fri, Feb 2, 2024 at 2:21 PM Michael Paquier wrote:
>
> On Fri, Feb 02, 2024 at 09:40:56AM +0900, Sutou Kouhei wrote:
> > Thanks. It'll help us.
>
> I have done a review of v10, see v11 attached which is still WIP, with
> the patches for COPY TO and COPY FROM merged together. Note that I'm
>
On Fri, Feb 02, 2024 at 09:40:56AM +0900, Sutou Kouhei wrote:
> Thanks. It'll help us.
I have done a review of v10, see v11 attached which is still WIP, with
the patches for COPY TO and COPY FROM merged together. Note that I'm
thinking to merge them into a single commit.
@@ -74,11 +75,11 @@
On Fri, Feb 02, 2024 at 06:51:02AM +0900, Michael Paquier wrote:
> I am going to try to plug in some rusage() calls in the backend for
> the COPY paths. I hope that gives more precision about the backend
> activity. I'll post that with more numbers.
And here they are with log_statement_stats
Hi,
In
"Re: Make COPY format extendable: Extract COPY TO format implementations" on
Fri, 2 Feb 2024 06:51:02 +0900,
Michael Paquier wrote:
> On Fri, Feb 02, 2024 at 12:19:51AM +0900, Sutou Kouhei wrote:
>> Here are some numbers on my local machine (Note that my
>
On Fri, Feb 02, 2024 at 12:19:51AM +0900, Sutou Kouhei wrote:
> Here are some numbers on my local machine (Note that my
> local machine isn't suitable for benchmark as I said
> before. Each number is median of "\watch 15" results):
>>
> I'll measure again on my local machine later. I'll stop
>
Hi,
Thanks for preparing benchmark.
In
"Re: Make COPY format extendable: Extract COPY TO format implementations" on
Thu, 1 Feb 2024 12:49:59 +0900,
Michael Paquier wrote:
> On Thu, Feb 01, 2024 at 10:57:58AM +0900, Michael Paquier wrote:
>> And here are the res
On Thu, Feb 1, 2024 at 11:56 AM Michael Paquier wrote:
>
> On Thu, Feb 01, 2024 at 11:43:07AM +0800, Junwang Zhao wrote:
> > The first 6 rounds are like 10% better than the later 9 rounds, is this
> > normal?
>
> Even with HEAD? Perhaps you have some OS cache eviction in play here?
> FWIW, I'm
On Thu, Feb 01, 2024 at 11:43:07AM +0800, Junwang Zhao wrote:
> The first 6 rounds are like 10% better than the later 9 rounds, is this
> normal?
Even with HEAD? Perhaps you have some OS cache eviction in play here?
FWIW, I'm not seeing any of that with longer runs after 7~ tries in a
loop of
On Thu, Feb 01, 2024 at 10:57:58AM +0900, Michael Paquier wrote:
> And here are the results I get for text and binary (ms, average of 15
> queries after discarding the three highest and three lowest values):
> test | master | v7 | v10
> -++--+--
>
Hi Michael,
On Thu, Feb 1, 2024 at 9:58 AM Michael Paquier wrote:
>
> On Wed, Jan 31, 2024 at 02:39:54PM +0900, Michael Paquier wrote:
> > Thanks, I'm looking into that now.
>
> I have much to say about the patch, but for now I have begun running
> some performance tests using the patches,
On Wed, Jan 31, 2024 at 02:39:54PM +0900, Michael Paquier wrote:
> Thanks, I'm looking into that now.
I have much to say about the patch, but for now I have begun running
some performance tests using the patches, because this thread won't
get far until we are sure that the callbacks do not impact
On Wed, Jan 31, 2024 at 02:11:22PM +0900, Sutou Kouhei wrote:
> Ah, yes. defel->location is used in later patches. For
> example, it's used when a COPY handler for the specified
> FORMAT isn't found.
I see.
> I've prepared the v10 patch set. Could you try this?
Thanks, I'm looking into that
Hi,
In
"Re: Make COPY format extendable: Extract COPY TO format implementations" on
Tue, 30 Jan 2024 17:37:35 +0900,
Michael Paquier wrote:
>> We use defel->location for an error message. (We don't need
>> to set location for the default "text" DefElem.)
On Tue, Jan 30, 2024 at 05:15:11PM +0900, Sutou Kouhei wrote:
> We use defel->location for an error message. (We don't need
> to set location for the default "text" DefElem.)
Yeah, but you should not need to have this error in the paths that set
the callback routines in opts_out if the same
Hi,
In
"Re: Make COPY format extendable: Extract COPY TO format implementations" on
Tue, 30 Jan 2024 16:20:54 +0900,
Michael Paquier wrote:
>>> +if (!format_specified)
>>> +/* Set the default format. */
>>> +
On Tue, Jan 30, 2024 at 02:45:31PM +0900, Sutou Kouhei wrote:
> In
> "Re: Make COPY format extendable: Extract COPY TO format implementations"
> on Tue, 30 Jan 2024 11:11:59 +0900,
> Masahiko Sawada wrote:
>
>> ---
>> +if (!format_specified)
&
Hi,
In
"Re: Make COPY format extendable: Extract COPY TO format implementations" on
Tue, 30 Jan 2024 11:11:59 +0900,
Masahiko Sawada wrote:
> ---
> +if (!format_specified)
> +/* Set the default format. */
> +ProcessCop
On Mon, Jan 29, 2024 at 6:45 PM Sutou Kouhei wrote:
>
> Hi,
>
> In
> "Re: Make COPY format extendable: Extract COPY TO format implementations"
> on Mon, 29 Jan 2024 11:37:07 +0800,
> Junwang Zhao wrote:
>
> >> > > Does it make sen
Hi,
In
"Re: Make COPY format extendable: Extract COPY TO format implementations" on
Mon, 29 Jan 2024 11:37:07 +0800,
Junwang Zhao wrote:
>> > > Does it make sense to pass only non-builtin options to the custom
>> > > format callback after parsing
On Mon, Jan 29, 2024 at 2:03 PM Sutou Kouhei wrote:
>
> Hi,
>
> In
> "Re: Make COPY format extendable: Extract COPY TO format implementations"
> on Sat, 27 Jan 2024 14:15:02 +0800,
> Junwang Zhao wrote:
>
> > I have been working on a *COPY TO JS
Hi,
In
"Re: Make COPY format extendable: Extract COPY TO format implementations" on
Sat, 27 Jan 2024 14:15:02 +0800,
Junwang Zhao wrote:
> I have been working on a *COPY TO JSON* extension since yesterday,
> which is based on your V6 patch set, I'd like to give you more in
> > >
> > > > On Fri, Jan 26, 2024 at 4:55 PM Sutou Kouhei
> > > > wrote:
> > > > >
> > > > > Hi,
> > > > >
> > > > > In
> > > > >
> > > > > "Re: Make COPY format
>
> > > > Hi,
> > > >
> > > > In
> > > > "Re: Make COPY format extendable: Extract COPY TO format
> > > > implementations" on Fri, 26 Jan 2024 16:41:50 +0800,
> > > > Junwang Zhao wrote:
> > >
On Mon, Jan 29, 2024 at 10:42 AM Masahiko Sawada wrote:
>
> On Fri, Jan 26, 2024 at 6:02 PM Junwang Zhao wrote:
> >
> > On Fri, Jan 26, 2024 at 4:55 PM Sutou Kouhei wrote:
> > >
> > > Hi,
> > >
> > > In
> > > "Re: Make C
On Fri, Jan 26, 2024 at 6:02 PM Junwang Zhao wrote:
>
> On Fri, Jan 26, 2024 at 4:55 PM Sutou Kouhei wrote:
> >
> > Hi,
> >
> > In
> > "Re: Make COPY format extendable: Extract COPY TO format implementations"
> > on Fri, 2
On Fri, Jan 26, 2024 at 4:55 PM Sutou Kouhei wrote:
>
> Hi,
>
> In
> "Re: Make COPY format extendable: Extract COPY TO format implementations"
> on Fri, 26 Jan 2024 16:41:50 +0800,
> Junwang Zhao wrote:
>
> > CopyToProcessOption()/CopyFromProcessOp
Hi,
In
"Re: Make COPY format extendable: Extract COPY TO format implementations" on
Fri, 26 Jan 2024 16:41:50 +0800,
Junwang Zhao wrote:
> CopyToProcessOption()/CopyFromProcessOption() can only handle
> single option, and store the options in the opaque field, but it
Hi,
In
"Re: Make COPY format extendable: Extract COPY TO format implementations" on
Fri, 26 Jan 2024 08:35:19 +0900,
Michael Paquier wrote:
>> OK. How about the following for the fetch function
>> signature?
>>
>> extern CopyToRoutine *GetBuilt
On Fri, Jan 26, 2024 at 4:32 PM Sutou Kouhei wrote:
>
> Hi,
>
> In
> "Re: Make COPY format extendable: Extract COPY TO format implementations"
> on Fri, 26 Jan 2024 16:18:14 +0800,
> Junwang Zhao wrote:
>
> > In the current implementa
Hi,
In
"Re: Make COPY format extendable: Extract COPY TO format implementations" on
Fri, 26 Jan 2024 16:18:14 +0800,
Junwang Zhao wrote:
> In the current implementation, there is no way that one can check
> incompatibility
> options in ProcessCopyOptions, we can
On Thu, Jan 25, 2024 at 4:52 PM Sutou Kouhei wrote:
>
> Hi,
>
> In
> "Re: Make COPY format extendable: Extract COPY TO format implementations"
> on Thu, 25 Jan 2024 13:36:03 +0900,
> Masahiko Sawada wrote:
>
> > I've experime
On Thu, Jan 25, 2024 at 05:45:43PM +0900, Sutou Kouhei wrote:
> In
> "Re: Make COPY format extendable: Extract COPY TO format implementations"
> on Thu, 25 Jan 2024 12:17:55 +0900,
> Michael Paquier wrote:
>> +extern CopyToRoutine CopyToRoutineText;
>> +ext
Hi,
In
"Re: Make COPY format extendable: Extract COPY TO format implementations" on
Thu, 25 Jan 2024 13:36:03 +0900,
Masahiko Sawada wrote:
> I've experimented with a similar optimization for csv
> and text format; have different callbacks for tex
Hi,
In
"Re: Make COPY format extendable: Extract COPY TO format implementations" on
Thu, 25 Jan 2024 12:17:55 +0900,
Michael Paquier wrote:
> +typedef bool (*CopyToProcessOption_function) (CopyToState cstate, DefElem
> *defel);
> +typedef int16 (*CopyToGetFormat_fun
Hi,
Thanks for trying these patches!
In
"Re: Make COPY format extendable: Extract COPY TO format implementations" on
Thu, 25 Jan 2024 10:53:58 +0800,
jian he wrote:
> COPY data TO '/dev/null' WITH (FORMAT csv) \watch count=5
Wow! I didn't know the "\watch count="
On Thu, Jan 25, 2024 at 1:53 PM Michael Paquier wrote:
>
> On Thu, Jan 25, 2024 at 01:36:03PM +0900, Masahiko Sawada wrote:
> > Hmm I can see a similar trend that Suto-san had; the binary format got
> > slightly faster whereas both text and csv format has small regression
> > (4%~5%). I think
On Thu, Jan 25, 2024 at 01:36:03PM +0900, Masahiko Sawada wrote:
> Hmm I can see a similar trend that Suto-san had; the binary format got
> slightly faster whereas both text and csv format has small regression
> (4%~5%). I think that the improvement for binary came from the fact
> that we removed
On Wed, Jan 24, 2024 at 11:17 PM Sutou Kouhei wrote:
>
> Hi,
>
> In <10025bac-158c-ffe7-fbec-32b426291...@dunslane.net>
> "Re: Make COPY format extendable: Extract COPY TO format implementations"
> on Wed, 24 Jan 2024 07:15:55 -0500,
> Andrew Dunstan wr
On Thu, Jan 25, 2024 at 10:53:58AM +0800, jian he wrote:
> apply your patch:
> COPY data TO '/dev/null' WITH (FORMAT csv) \watch count=5
> Time: 668.996 ms
> Time: 596.254 ms
> Time: 592.723 ms
> Time: 591.663 ms
> Time: 590.803 ms
>
> not apply your patch, at git
On Wed, Jan 24, 2024 at 11:17:26PM +0900, Sutou Kouhei wrote:
> In <10025bac-158c-ffe7-fbec-32b426291...@dunslane.net>
> "Re: Make COPY format extendable: Extract COPY TO format implementations"
> on Wed, 24 Jan 2024 07:15:55 -0500,
> Andrew Dunstan wrote:
>>
On Wed, Jan 24, 2024 at 10:17 PM Sutou Kouhei wrote:
>
> I uploaded my benchmark script so that you can run the same
> benchmark on your machine:
>
> https://gist.github.com/kou/be02e02e5072c91969469dbf137b5de5
>
> Could anyone try the benchmark with master and master+0001?
>
sorry. I made a
Hi,
In <20240124.144936.67229716500876806@clear-code.com>
"Re: Make COPY format extendable: Extract COPY TO format implementations" on
Wed, 24 Jan 2024 14:49:36 +0900 (JST),
Sutou Kouhei wrote:
> I've implemented custom COPY format feature based on the
> current
Hi,
In <10025bac-158c-ffe7-fbec-32b426291...@dunslane.net>
"Re: Make COPY format extendable: Extract COPY TO format implementations" on
Wed, 24 Jan 2024 07:15:55 -0500,
Andrew Dunstan wrote:
>
> On 2024-01-24 We 03:11, Michael Paquier wrote:
>> On Wed, Jan
On 2024-01-24 We 03:11, Michael Paquier wrote:
On Wed, Jan 24, 2024 at 02:49:36PM +0900, Sutou Kouhei wrote:
For COPY TO:
0001: This adds CopyToRoutine and use it for text/csv/binary
formats. No implementation change. This just move codes.
10M without this change:
format,elapsed time
On Wed, Jan 24, 2024 at 02:49:36PM +0900, Sutou Kouhei wrote:
> For COPY TO:
>
> 0001: This adds CopyToRoutine and use it for text/csv/binary
> formats. No implementation change. This just move codes.
10M without this change:
format,elapsed time (ms)
text,1090.763
csv,1136.103
. CopyReadBinaryData() is renamed to
CopyFromStateRead().
Thanks,
--
kou
In <20240115.152702.2011620917962812379@clear-code.com>
"Re: Make COPY format extendable: Extract COPY TO format implementations" on
Mon, 15 Jan 2024 15:27:02 +0900 (JST),
Sutou Kouhei wrote:
>
Hi,
In
"Re: Make COPY format extendable: Extract COPY TO format implementations" on
Mon, 15 Jan 2024 16:03:41 +0900,
Masahiko Sawada wrote:
>> Defining one more static const struct instead of providing a
>> convenient (but a bit tricky) macro may be straightforwa
On Thu, Jan 11, 2024 at 10:24 AM Sutou Kouhei wrote:
>
> Hi,
>
> In
> "Re: Make COPY format extendable: Extract COPY TO format implementations"
> on Wed, 10 Jan 2024 16:53:48 +0900,
> Masahiko Sawada wrote:
>
> >> Interesting. But I feel tha
0]
I'll export Copy{To,From}State.
Thanks,
--
kou
In <20240112.144615.157925223373344229@clear-code.com>
"Re: Make COPY format extendable: Extract COPY TO format implementations" on
Fri, 12 Jan 2024 14:46:15 +0900 (JST),
Sutou Kouhei wrote:
> Hi,
>
> Here is the c
Hi,
In
"Re: Make COPY format extendable: Extract COPY TO format implementations" on
Fri, 12 Jan 2024 14:40:41 +0800,
Junwang Zhao wrote:
>> Could you clarify what should we discuss? We should require
>> that COPY TO/FROM handlers should use PostgreSQL's memory
>&
Hi,
On Wed, Jan 10, 2024 at 2:20 PM Sutou Kouhei wrote:
>
> Hi,
>
> In
> "Re: Make COPY format extendable: Extract COPY TO format implementations"
> on Fri, 22 Dec 2023 10:58:05 +0800,
> Junwang Zhao wrote:
>
> >> 1. Add an opaque space for custo
Hi,
Here is the current summary for a this discussion to make
COPY format extendable. It's for reaching consensus and
starting implementing the feature. (I'll start implementing
the feature once we reach consensus.) If you have any
opinion, please share it.
Confirmed:
1.1 Making COPY format
1 - 100 of 154 matches
Mail list logo
