Re: COPY (INSERT/UPDATE/DELETE .. RETURNING ..)

On 2015-11-16 08:24, Michael Paquier wrote:
> On Sun, Nov 1, 2015 at 2:49 AM, Marko Tiikkaja <marko(at)joh(dot)to> wrote:
>> Attached is a patch for being able to do $SUBJECT without a CTE. The
>> reasons this is better than a CTE version are:
>>
>> 1) It's not obvious why a CTE version works but a plain one doesn't
>> 2) This one has less overhead (I measured a ~12% improvement on a
>> not-too-unreasonable test case)
>
> Would you mind sharing this test case as well as numbers?

I'll try and re-puzzle it together tomorrow. It looks like I wasn't
smart enough to actually save the test case anywhere.

> Regression tests are broken when copyselect is run in parallel because
> test3 is a table used there as well. A simple idea to fix this is to rename
> the table test3 to something else or to use a schema dedicated to this
> test, I just renamed it to copydml_test in the patch attached.

Seems reasonable.

> - | COPY select_with_parens TO opt_program
> copy_file_name opt_with copy_options
> + | COPY '(' PreparableStmt ')' TO opt_program
> copy_file_name opt_with copy_options
> This does not look right, PreparableStmt is used for statements that are
> part of PREPARE queries, any modifications happening there would impact
> COPY with this implementation. I think that we had better have a new option
> query_with_parens. Please note that the patch attached has not changed that.

This was discussed in 2010 when CTEs got the same treatment, and I agree
with what was decided back then. If someone needs to make
PreparableStmt different from what COPY and CTEs support, we can split
them up. But they're completely identical after this patch, so
splitting them up right now is somewhat pointless.

Further, if someone's going to add new stuff to PreparableStmt, she
should probably think about whether it would make sense to add it to
COPY and CTEs from day one, too, and in that case not splitting them up
is actually a win.

.m