On 2015-11-16 08:24, Michael Paquier wrote:
On Sun, Nov 1, 2015 at 2:49 AM, Marko Tiikkaja <ma...@joh.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


--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Reply via email to