agora inbox for pgsql-hackers@postgresql.orghelp / color / mirror / Atom feed
[PATCH v4 2/8] Documentation 3+ messages / 2 participants [nested] [flat]
* [PATCH v4 2/8] Documentation @ 2019-05-15 05:50 David Fetter <david@fetter.org> 0 siblings, 0 replies; 3+ messages in thread From: David Fetter @ 2019-05-15 05:50 UTC (permalink / raw) diff --git a/doc/src/sgml/ref/explain.sgml b/doc/src/sgml/ref/explain.sgml index 385d10411f..63a3faede8 100644 --- a/doc/src/sgml/ref/explain.sgml +++ b/doc/src/sgml/ref/explain.sgml @@ -32,11 +32,11 @@ PostgreSQL documentation <refsynopsisdiv> <synopsis> EXPLAIN [ ( <replaceable class="parameter">option</replaceable> [, ...] ) ] <replaceable class="parameter">statement</replaceable> -EXPLAIN [ ANALYZE ] [ VERBOSE ] <replaceable class="parameter">statement</replaceable> +EXPLAIN [ EXEC ] [ VERBOSE ] <replaceable class="parameter">statement</replaceable> <phrase>where <replaceable class="parameter">option</replaceable> can be one of:</phrase> - ANALYZE [ <replaceable class="parameter">boolean</replaceable> ] + EXEC [ <replaceable class="parameter">boolean</replaceable> ] VERBOSE [ <replaceable class="parameter">boolean</replaceable> ] COSTS [ <replaceable class="parameter">boolean</replaceable> ] SETTINGS [ <replaceable class="parameter">boolean</replaceable> ] @@ -76,36 +76,37 @@ EXPLAIN [ ANALYZE ] [ VERBOSE ] <replaceable class="parameter">statement</replac </para> <para> - The <literal>ANALYZE</literal> option causes the statement to be actually + The <literal>EXEC</literal> option causes the statement to be actually executed, not only planned. Then actual run time statistics are added to the display, including the total elapsed time expended within each plan node (in milliseconds) and the total number of rows it actually returned. This is useful for seeing whether the planner's estimates - are close to reality. + are close to reality. For historical reasons, ANALYZE and ANALYSE can be + used instead of EXEC. </para> <important> <para> Keep in mind that the statement is actually executed when - the <literal>ANALYZE</literal> option is used. Although + the <literal>EXEC</literal> option is used. Although <command>EXPLAIN</command> will discard any output that a <command>SELECT</command> would return, other side effects of the statement will happen as usual. If you wish to use - <command>EXPLAIN ANALYZE</command> on an + <command>EXPLAIN EXEC</command> on an <command>INSERT</command>, <command>UPDATE</command>, <command>DELETE</command>, <command>CREATE TABLE AS</command>, or <command>EXECUTE</command> statement without letting the command affect your data, use this approach: <programlisting> BEGIN; -EXPLAIN ANALYZE ...; +EXPLAIN EXEC ...; ROLLBACK; </programlisting> </para> </important> <para> - Only the <literal>ANALYZE</literal> and <literal>VERBOSE</literal> options + Only the <literal>EXEC</literal> and <literal>VERBOSE</literal> options can be specified, and only in that order, without surrounding the option list in parentheses. Prior to <productname>PostgreSQL</productname> 9.0, the unparenthesized syntax was the only one supported. It is expected that @@ -118,7 +119,7 @@ ROLLBACK; <variablelist> <varlistentry> - <term><literal>ANALYZE</literal></term> + <term><literal>EXEC</literal></term> <listitem> <para> Carry out the command and show actual run times and other statistics. @@ -159,7 +160,7 @@ ROLLBACK; <para> Include information on configuration parameters. Specifically, include options affecting query planning with value different from the built-in - default value. This parameter defaults to <literal>FALSE</literal>. + default value. This parameter defaults to <literal>TRUE</literal>. </para> </listitem> </varlistentry> @@ -186,8 +187,8 @@ ROLLBACK; The number of blocks shown for an upper-level node includes those used by all its child nodes. In text format, only non-zero values are printed. This parameter may only be - used when <literal>ANALYZE</literal> is also enabled. It defaults to - <literal>FALSE</literal>. + used when <literal>EXEC</literal> is also enabled. It defaults to + <literal>TRUE</literal>. </para> </listitem> </varlistentry> @@ -203,7 +204,7 @@ ROLLBACK; not exact times, are needed. Run time of the entire statement is always measured, even when node-level timing is turned off with this option. - This parameter may only be used when <literal>ANALYZE</literal> is also + This parameter may only be used when <literal>EXEC</literal> is also enabled. It defaults to <literal>TRUE</literal>. </para> </listitem> @@ -215,9 +216,9 @@ ROLLBACK; <para> Include summary information (e.g., totaled timing information) after the query plan. Summary information is included by default when - <literal>ANALYZE</literal> is used but otherwise is not included by + <literal>EXEC</literal> is used but otherwise is not included by default, but can be enabled using this option. Planning time in - <command>EXPLAIN EXECUTE</command> includes the time required to fetch + <command>EXPLAIN EXEC</command> includes the time required to fetch the plan from the cache and the time required for re-planning, if necessary. </para> @@ -295,8 +296,8 @@ ROLLBACK; <para> In order to measure the run-time cost of each node in the execution plan, the current implementation of <command>EXPLAIN - ANALYZE</command> adds profiling overhead to query execution. - As a result, running <command>EXPLAIN ANALYZE</command> + EXEC</command> adds profiling overhead to query execution. + As a result, running <command>EXPLAIN EXEC</command> on a query can sometimes take significantly longer than executing the query normally. The amount of overhead depends on the nature of the query, as well as the platform being used. The worst case occurs @@ -423,7 +424,7 @@ PREPARE query(int, int) AS SELECT sum(bar) FROM test WHERE id > $1 AND id < $2 GROUP BY foo; -EXPLAIN ANALYZE EXECUTE query(100, 200); +EXPLAIN EXEC EXECUTE query(100, 200); QUERY PLAN ------------------------------------------------------------------------------------------------------------------------ ^ permalink raw reply [nested|flat] 3+ messages in thread
* [PATCH v5 2/8] Documentation @ 2019-05-18 18:07 David Fetter <david@fetter.org> 0 siblings, 0 replies; 3+ messages in thread From: David Fetter @ 2019-05-18 18:07 UTC (permalink / raw) diff --git a/doc/src/sgml/ref/explain.sgml b/doc/src/sgml/ref/explain.sgml index 385d10411f..d79bddb68e 100644 --- a/doc/src/sgml/ref/explain.sgml +++ b/doc/src/sgml/ref/explain.sgml @@ -32,11 +32,12 @@ PostgreSQL documentation <refsynopsisdiv> <synopsis> EXPLAIN [ ( <replaceable class="parameter">option</replaceable> [, ...] ) ] <replaceable class="parameter">statement</replaceable> -EXPLAIN [ ANALYZE ] [ VERBOSE ] <replaceable class="parameter">statement</replaceable> +Legacy syntax: +EXPLAIN [ { ANALYZE | ANALYSE } ] [ VERBOSE ] <replaceable class="parameter">statement</replaceable> <phrase>where <replaceable class="parameter">option</replaceable> can be one of:</phrase> - ANALYZE [ <replaceable class="parameter">boolean</replaceable> ] + EXEC [ <replaceable class="parameter">boolean</replaceable> ] VERBOSE [ <replaceable class="parameter">boolean</replaceable> ] COSTS [ <replaceable class="parameter">boolean</replaceable> ] SETTINGS [ <replaceable class="parameter">boolean</replaceable> ] @@ -76,7 +77,7 @@ EXPLAIN [ ANALYZE ] [ VERBOSE ] <replaceable class="parameter">statement</replac </para> <para> - The <literal>ANALYZE</literal> option causes the statement to be actually + The <literal>EXEC</literal> option causes the statement to be actually executed, not only planned. Then actual run time statistics are added to the display, including the total elapsed time expended within each plan node (in milliseconds) and the total number of rows it actually returned. @@ -87,18 +88,18 @@ EXPLAIN [ ANALYZE ] [ VERBOSE ] <replaceable class="parameter">statement</replac <important> <para> Keep in mind that the statement is actually executed when - the <literal>ANALYZE</literal> option is used. Although + the <literal>EXEC</literal> option is used. Although <command>EXPLAIN</command> will discard any output that a <command>SELECT</command> would return, other side effects of the statement will happen as usual. If you wish to use - <command>EXPLAIN ANALYZE</command> on an + <command>EXPLAIN (EXEC)</command> on an <command>INSERT</command>, <command>UPDATE</command>, <command>DELETE</command>, <command>CREATE TABLE AS</command>, or <command>EXECUTE</command> statement without letting the command affect your data, use this approach: <programlisting> BEGIN; -EXPLAIN ANALYZE ...; +EXPLAIN (EXEC) ...; ROLLBACK; </programlisting> </para> @@ -118,7 +119,7 @@ ROLLBACK; <variablelist> <varlistentry> - <term><literal>ANALYZE</literal></term> + <term><literal>EXEC</literal></term> <listitem> <para> Carry out the command and show actual run times and other statistics. @@ -186,7 +187,7 @@ ROLLBACK; The number of blocks shown for an upper-level node includes those used by all its child nodes. In text format, only non-zero values are printed. This parameter may only be - used when <literal>ANALYZE</literal> is also enabled. It defaults to + used when <literal>EXEC</literal> is also enabled. It defaults to <literal>FALSE</literal>. </para> </listitem> @@ -203,7 +204,7 @@ ROLLBACK; not exact times, are needed. Run time of the entire statement is always measured, even when node-level timing is turned off with this option. - This parameter may only be used when <literal>ANALYZE</literal> is also + This parameter may only be used when <literal>EXEC</literal> is also enabled. It defaults to <literal>TRUE</literal>. </para> </listitem> @@ -215,7 +216,7 @@ ROLLBACK; <para> Include summary information (e.g., totaled timing information) after the query plan. Summary information is included by default when - <literal>ANALYZE</literal> is used but otherwise is not included by + <literal>EXEC</literal> is used but otherwise is not included by default, but can be enabled using this option. Planning time in <command>EXPLAIN EXECUTE</command> includes the time required to fetch the plan from the cache and the time required for re-planning, if @@ -295,8 +296,8 @@ ROLLBACK; <para> In order to measure the run-time cost of each node in the execution plan, the current implementation of <command>EXPLAIN - ANALYZE</command> adds profiling overhead to query execution. - As a result, running <command>EXPLAIN ANALYZE</command> + (EXEC)</command> adds profiling overhead to query execution. + As a result, running <command>EXPLAIN (EXEC)</command> on a query can sometimes take significantly longer than executing the query normally. The amount of overhead depends on the nature of the query, as well as the platform being used. The worst case occurs @@ -423,7 +424,7 @@ PREPARE query(int, int) AS SELECT sum(bar) FROM test WHERE id > $1 AND id < $2 GROUP BY foo; -EXPLAIN ANALYZE EXECUTE query(100, 200); +EXPLAIN (EXEC) EXECUTE query(100, 200); QUERY PLAN ------------------------------------------------------------------------------------------------------------------------ ^ permalink raw reply [nested|flat] 3+ messages in thread
* Review observations for COPY ON_ERROR_TABLE patch @ 2026-05-18 06:55 vellaipandiyan sm <vellaipandiyan.sm@gmail.com> 0 siblings, 0 replies; 3+ messages in thread From: vellaipandiyan sm @ 2026-05-18 06:55 UTC (permalink / raw) To: pgsql-hackers@lists.postgresql.org Hello hackers, I was reviewing the COPY ON_ERROR_TABLE patch and had a few implementation questions that may be worth considering. - The COPY multi-insert path currently depends on CopyMultiInsertBuffer and table_multi_insert() batching behavior. Recovering from row-level failures while buffers are partially populated may complicate buffer consistency, trigger visibility, or index handling. - Would it make sense to initially disable multi-insert batching when ON_ERROR_TABLE is enabled (forcing CIM_SINGLE)? That seems like a simpler starting point for correctness and recovery semantics. - I was also curious about the intended transaction behavior for rejected rows. Should rows written to the error table rollback together with the surrounding COPY transaction if a later failure occurs? - Another possible edge case is recursive failure handling if insertion into the error table itself fails. I have not yet reproduced a concrete failure case, so these are currently review observations rather than confirmed issues. Thanks for working on this feature. Regards, Vellaipandiyan ^ permalink raw reply [nested|flat] 3+ messages in thread
end of thread, other threads:[~2026-05-18 06:55 UTC | newest] Thread overview: 3+ messages (download: mbox mbox.gz follow: Atom feed) -- links below jump to the message on this page -- 2019-05-15 05:50 [PATCH v4 2/8] Documentation David Fetter <david@fetter.org> 2019-05-18 18:07 [PATCH v5 2/8] Documentation David Fetter <david@fetter.org> 2026-05-18 06:55 Review observations for COPY ON_ERROR_TABLE patch vellaipandiyan sm <vellaipandiyan.sm@gmail.com>
This inbox is served by agora; see mirroring instructions for how to clone and mirror all data and code used for this inbox