agora inbox for [email protected]
help / color / mirror / Atom feed[PATCH] doc review: COPY progress: 8a4f618e7ae3cb11b0b37d0f06f05c8ff905833f
54+ messages / 6 participants
[nested] [flat]
* [PATCH] doc review: COPY progress: 8a4f618e7ae3cb11b0b37d0f06f05c8ff905833f
@ 2021-01-07 01:08 Justin Pryzby <[email protected]>
0 siblings, 0 replies; 54+ messages in thread
From: Justin Pryzby @ 2021-01-07 01:08 UTC (permalink / raw)
---
doc/src/sgml/monitoring.sgml | 10 +++++-----
1 file changed, 5 insertions(+), 5 deletions(-)
diff --git a/doc/src/sgml/monitoring.sgml b/doc/src/sgml/monitoring.sgml
index 43fe8ae383..3cdb1aff3c 100644
--- a/doc/src/sgml/monitoring.sgml
+++ b/doc/src/sgml/monitoring.sgml
@@ -6414,9 +6414,9 @@ SELECT pg_stat_get_backend_pid(s.backendid) AS pid,
<para>
Whenever <command>COPY</command> is running, the
<structname>pg_stat_progress_copy</structname> view will contain one row
- for each backend that is currently running <command>COPY</command> command.
- The table bellow describes the information that will be reported and provide
- information how to interpret it.
+ for each backend that is currently running a <command>COPY</command> command.
+ The table below describes the information that will be reported and provides
+ information about how to interpret it.
</para>
<table id="pg-stat-progress-copy-view" xreflabel="pg_stat_progress_copy">
@@ -6445,7 +6445,7 @@ SELECT pg_stat_get_backend_pid(s.backendid) AS pid,
<row>
<entry role="catalog_table_entry"><para role="column_definition">
- <structfield>datid</structfield> <type>text</type>
+ <structfield>datid</structfield> <type>oid</type>
</para>
<para>
OID of the database to which this backend is connected.
@@ -6467,7 +6467,7 @@ SELECT pg_stat_get_backend_pid(s.backendid) AS pid,
</para>
<para>
OID of the table on which the <command>COPY</command> command is executed.
- It is set to 0 if <command>SELECT</command> query is provided.
+ It is set to 0 if copying from a <command>SELECT</command> query.
</para></entry>
</row>
--
2.17.0
--aM3YZ0Iwxop3KEKx
Content-Type: text/x-diff; charset=us-ascii
Content-Disposition: attachment;
filename="0001-doc-review-COPY-progress-8a4f618e7ae3cb11b0b37d0f06f.patch"
^ permalink raw reply [nested|flat] 54+ messages in thread
* [PATCH] doc review: COPY progress: 8a4f618e7ae3cb11b0b37d0f06f05c8ff905833f
@ 2021-01-07 01:08 Justin Pryzby <[email protected]>
0 siblings, 0 replies; 54+ messages in thread
From: Justin Pryzby @ 2021-01-07 01:08 UTC (permalink / raw)
---
doc/src/sgml/monitoring.sgml | 10 +++++-----
1 file changed, 5 insertions(+), 5 deletions(-)
diff --git a/doc/src/sgml/monitoring.sgml b/doc/src/sgml/monitoring.sgml
index 43fe8ae383..3cdb1aff3c 100644
--- a/doc/src/sgml/monitoring.sgml
+++ b/doc/src/sgml/monitoring.sgml
@@ -6414,9 +6414,9 @@ SELECT pg_stat_get_backend_pid(s.backendid) AS pid,
<para>
Whenever <command>COPY</command> is running, the
<structname>pg_stat_progress_copy</structname> view will contain one row
- for each backend that is currently running <command>COPY</command> command.
- The table bellow describes the information that will be reported and provide
- information how to interpret it.
+ for each backend that is currently running a <command>COPY</command> command.
+ The table below describes the information that will be reported and provides
+ information about how to interpret it.
</para>
<table id="pg-stat-progress-copy-view" xreflabel="pg_stat_progress_copy">
@@ -6445,7 +6445,7 @@ SELECT pg_stat_get_backend_pid(s.backendid) AS pid,
<row>
<entry role="catalog_table_entry"><para role="column_definition">
- <structfield>datid</structfield> <type>text</type>
+ <structfield>datid</structfield> <type>oid</type>
</para>
<para>
OID of the database to which this backend is connected.
@@ -6467,7 +6467,7 @@ SELECT pg_stat_get_backend_pid(s.backendid) AS pid,
</para>
<para>
OID of the table on which the <command>COPY</command> command is executed.
- It is set to 0 if <command>SELECT</command> query is provided.
+ It is set to 0 if copying from a <command>SELECT</command> query.
</para></entry>
</row>
--
2.17.0
--aM3YZ0Iwxop3KEKx
Content-Type: text/x-diff; charset=us-ascii
Content-Disposition: attachment;
filename="0001-doc-review-COPY-progress-8a4f618e7ae3cb11b0b37d0f06f.patch"
^ permalink raw reply [nested|flat] 54+ messages in thread
* [PATCH] doc review: COPY progress: 8a4f618e7ae3cb11b0b37d0f06f05c8ff905833f
@ 2021-01-07 01:08 Justin Pryzby <[email protected]>
0 siblings, 0 replies; 54+ messages in thread
From: Justin Pryzby @ 2021-01-07 01:08 UTC (permalink / raw)
---
doc/src/sgml/monitoring.sgml | 10 +++++-----
1 file changed, 5 insertions(+), 5 deletions(-)
diff --git a/doc/src/sgml/monitoring.sgml b/doc/src/sgml/monitoring.sgml
index 43fe8ae383..3cdb1aff3c 100644
--- a/doc/src/sgml/monitoring.sgml
+++ b/doc/src/sgml/monitoring.sgml
@@ -6414,9 +6414,9 @@ SELECT pg_stat_get_backend_pid(s.backendid) AS pid,
<para>
Whenever <command>COPY</command> is running, the
<structname>pg_stat_progress_copy</structname> view will contain one row
- for each backend that is currently running <command>COPY</command> command.
- The table bellow describes the information that will be reported and provide
- information how to interpret it.
+ for each backend that is currently running a <command>COPY</command> command.
+ The table below describes the information that will be reported and provides
+ information about how to interpret it.
</para>
<table id="pg-stat-progress-copy-view" xreflabel="pg_stat_progress_copy">
@@ -6445,7 +6445,7 @@ SELECT pg_stat_get_backend_pid(s.backendid) AS pid,
<row>
<entry role="catalog_table_entry"><para role="column_definition">
- <structfield>datid</structfield> <type>text</type>
+ <structfield>datid</structfield> <type>oid</type>
</para>
<para>
OID of the database to which this backend is connected.
@@ -6467,7 +6467,7 @@ SELECT pg_stat_get_backend_pid(s.backendid) AS pid,
</para>
<para>
OID of the table on which the <command>COPY</command> command is executed.
- It is set to 0 if <command>SELECT</command> query is provided.
+ It is set to 0 if copying from a <command>SELECT</command> query.
</para></entry>
</row>
--
2.17.0
--aM3YZ0Iwxop3KEKx--
^ permalink raw reply [nested|flat] 54+ messages in thread
* [PATCH] doc review: COPY progress: 8a4f618e7ae3cb11b0b37d0f06f05c8ff905833f
@ 2021-01-07 01:08 Justin Pryzby <[email protected]>
0 siblings, 0 replies; 54+ messages in thread
From: Justin Pryzby @ 2021-01-07 01:08 UTC (permalink / raw)
---
doc/src/sgml/monitoring.sgml | 10 +++++-----
1 file changed, 5 insertions(+), 5 deletions(-)
diff --git a/doc/src/sgml/monitoring.sgml b/doc/src/sgml/monitoring.sgml
index 43fe8ae383..3cdb1aff3c 100644
--- a/doc/src/sgml/monitoring.sgml
+++ b/doc/src/sgml/monitoring.sgml
@@ -6414,9 +6414,9 @@ SELECT pg_stat_get_backend_pid(s.backendid) AS pid,
<para>
Whenever <command>COPY</command> is running, the
<structname>pg_stat_progress_copy</structname> view will contain one row
- for each backend that is currently running <command>COPY</command> command.
- The table bellow describes the information that will be reported and provide
- information how to interpret it.
+ for each backend that is currently running a <command>COPY</command> command.
+ The table below describes the information that will be reported and provides
+ information about how to interpret it.
</para>
<table id="pg-stat-progress-copy-view" xreflabel="pg_stat_progress_copy">
@@ -6445,7 +6445,7 @@ SELECT pg_stat_get_backend_pid(s.backendid) AS pid,
<row>
<entry role="catalog_table_entry"><para role="column_definition">
- <structfield>datid</structfield> <type>text</type>
+ <structfield>datid</structfield> <type>oid</type>
</para>
<para>
OID of the database to which this backend is connected.
@@ -6467,7 +6467,7 @@ SELECT pg_stat_get_backend_pid(s.backendid) AS pid,
</para>
<para>
OID of the table on which the <command>COPY</command> command is executed.
- It is set to 0 if <command>SELECT</command> query is provided.
+ It is set to 0 if copying from a <command>SELECT</command> query.
</para></entry>
</row>
--
2.17.0
--aM3YZ0Iwxop3KEKx
Content-Type: text/x-diff; charset=us-ascii
Content-Disposition: attachment;
filename="0001-doc-review-COPY-progress-8a4f618e7ae3cb11b0b37d0f06f.patch"
^ permalink raw reply [nested|flat] 54+ messages in thread
* [PATCH] doc review: COPY progress: 8a4f618e7ae3cb11b0b37d0f06f05c8ff905833f
@ 2021-01-07 01:08 Justin Pryzby <[email protected]>
0 siblings, 0 replies; 54+ messages in thread
From: Justin Pryzby @ 2021-01-07 01:08 UTC (permalink / raw)
---
doc/src/sgml/monitoring.sgml | 10 +++++-----
1 file changed, 5 insertions(+), 5 deletions(-)
diff --git a/doc/src/sgml/monitoring.sgml b/doc/src/sgml/monitoring.sgml
index 43fe8ae383..3cdb1aff3c 100644
--- a/doc/src/sgml/monitoring.sgml
+++ b/doc/src/sgml/monitoring.sgml
@@ -6414,9 +6414,9 @@ SELECT pg_stat_get_backend_pid(s.backendid) AS pid,
<para>
Whenever <command>COPY</command> is running, the
<structname>pg_stat_progress_copy</structname> view will contain one row
- for each backend that is currently running <command>COPY</command> command.
- The table bellow describes the information that will be reported and provide
- information how to interpret it.
+ for each backend that is currently running a <command>COPY</command> command.
+ The table below describes the information that will be reported and provides
+ information about how to interpret it.
</para>
<table id="pg-stat-progress-copy-view" xreflabel="pg_stat_progress_copy">
@@ -6445,7 +6445,7 @@ SELECT pg_stat_get_backend_pid(s.backendid) AS pid,
<row>
<entry role="catalog_table_entry"><para role="column_definition">
- <structfield>datid</structfield> <type>text</type>
+ <structfield>datid</structfield> <type>oid</type>
</para>
<para>
OID of the database to which this backend is connected.
@@ -6467,7 +6467,7 @@ SELECT pg_stat_get_backend_pid(s.backendid) AS pid,
</para>
<para>
OID of the table on which the <command>COPY</command> command is executed.
- It is set to 0 if <command>SELECT</command> query is provided.
+ It is set to 0 if copying from a <command>SELECT</command> query.
</para></entry>
</row>
--
2.17.0
--aM3YZ0Iwxop3KEKx--
^ permalink raw reply [nested|flat] 54+ messages in thread
* [PATCH] doc review: COPY progress: 8a4f618e7ae3cb11b0b37d0f06f05c8ff905833f
@ 2021-01-07 01:08 Justin Pryzby <[email protected]>
0 siblings, 0 replies; 54+ messages in thread
From: Justin Pryzby @ 2021-01-07 01:08 UTC (permalink / raw)
---
doc/src/sgml/monitoring.sgml | 10 +++++-----
1 file changed, 5 insertions(+), 5 deletions(-)
diff --git a/doc/src/sgml/monitoring.sgml b/doc/src/sgml/monitoring.sgml
index 43fe8ae383..3cdb1aff3c 100644
--- a/doc/src/sgml/monitoring.sgml
+++ b/doc/src/sgml/monitoring.sgml
@@ -6414,9 +6414,9 @@ SELECT pg_stat_get_backend_pid(s.backendid) AS pid,
<para>
Whenever <command>COPY</command> is running, the
<structname>pg_stat_progress_copy</structname> view will contain one row
- for each backend that is currently running <command>COPY</command> command.
- The table bellow describes the information that will be reported and provide
- information how to interpret it.
+ for each backend that is currently running a <command>COPY</command> command.
+ The table below describes the information that will be reported and provides
+ information about how to interpret it.
</para>
<table id="pg-stat-progress-copy-view" xreflabel="pg_stat_progress_copy">
@@ -6445,7 +6445,7 @@ SELECT pg_stat_get_backend_pid(s.backendid) AS pid,
<row>
<entry role="catalog_table_entry"><para role="column_definition">
- <structfield>datid</structfield> <type>text</type>
+ <structfield>datid</structfield> <type>oid</type>
</para>
<para>
OID of the database to which this backend is connected.
@@ -6467,7 +6467,7 @@ SELECT pg_stat_get_backend_pid(s.backendid) AS pid,
</para>
<para>
OID of the table on which the <command>COPY</command> command is executed.
- It is set to 0 if <command>SELECT</command> query is provided.
+ It is set to 0 if copying from a <command>SELECT</command> query.
</para></entry>
</row>
--
2.17.0
--aM3YZ0Iwxop3KEKx
Content-Type: text/x-diff; charset=us-ascii
Content-Disposition: attachment;
filename="0001-doc-review-COPY-progress-8a4f618e7ae3cb11b0b37d0f06f.patch"
^ permalink raw reply [nested|flat] 54+ messages in thread
* [PATCH] doc review: COPY progress: 8a4f618e7ae3cb11b0b37d0f06f05c8ff905833f
@ 2021-01-07 01:08 Justin Pryzby <[email protected]>
0 siblings, 0 replies; 54+ messages in thread
From: Justin Pryzby @ 2021-01-07 01:08 UTC (permalink / raw)
---
doc/src/sgml/monitoring.sgml | 10 +++++-----
1 file changed, 5 insertions(+), 5 deletions(-)
diff --git a/doc/src/sgml/monitoring.sgml b/doc/src/sgml/monitoring.sgml
index 43fe8ae383..3cdb1aff3c 100644
--- a/doc/src/sgml/monitoring.sgml
+++ b/doc/src/sgml/monitoring.sgml
@@ -6414,9 +6414,9 @@ SELECT pg_stat_get_backend_pid(s.backendid) AS pid,
<para>
Whenever <command>COPY</command> is running, the
<structname>pg_stat_progress_copy</structname> view will contain one row
- for each backend that is currently running <command>COPY</command> command.
- The table bellow describes the information that will be reported and provide
- information how to interpret it.
+ for each backend that is currently running a <command>COPY</command> command.
+ The table below describes the information that will be reported and provides
+ information about how to interpret it.
</para>
<table id="pg-stat-progress-copy-view" xreflabel="pg_stat_progress_copy">
@@ -6445,7 +6445,7 @@ SELECT pg_stat_get_backend_pid(s.backendid) AS pid,
<row>
<entry role="catalog_table_entry"><para role="column_definition">
- <structfield>datid</structfield> <type>text</type>
+ <structfield>datid</structfield> <type>oid</type>
</para>
<para>
OID of the database to which this backend is connected.
@@ -6467,7 +6467,7 @@ SELECT pg_stat_get_backend_pid(s.backendid) AS pid,
</para>
<para>
OID of the table on which the <command>COPY</command> command is executed.
- It is set to 0 if <command>SELECT</command> query is provided.
+ It is set to 0 if copying from a <command>SELECT</command> query.
</para></entry>
</row>
--
2.17.0
--aM3YZ0Iwxop3KEKx--
^ permalink raw reply [nested|flat] 54+ messages in thread
* [PATCH] doc review: COPY progress: 8a4f618e7ae3cb11b0b37d0f06f05c8ff905833f
@ 2021-01-07 01:08 Justin Pryzby <[email protected]>
0 siblings, 0 replies; 54+ messages in thread
From: Justin Pryzby @ 2021-01-07 01:08 UTC (permalink / raw)
---
doc/src/sgml/monitoring.sgml | 10 +++++-----
1 file changed, 5 insertions(+), 5 deletions(-)
diff --git a/doc/src/sgml/monitoring.sgml b/doc/src/sgml/monitoring.sgml
index 43fe8ae383..3cdb1aff3c 100644
--- a/doc/src/sgml/monitoring.sgml
+++ b/doc/src/sgml/monitoring.sgml
@@ -6414,9 +6414,9 @@ SELECT pg_stat_get_backend_pid(s.backendid) AS pid,
<para>
Whenever <command>COPY</command> is running, the
<structname>pg_stat_progress_copy</structname> view will contain one row
- for each backend that is currently running <command>COPY</command> command.
- The table bellow describes the information that will be reported and provide
- information how to interpret it.
+ for each backend that is currently running a <command>COPY</command> command.
+ The table below describes the information that will be reported and provides
+ information about how to interpret it.
</para>
<table id="pg-stat-progress-copy-view" xreflabel="pg_stat_progress_copy">
@@ -6445,7 +6445,7 @@ SELECT pg_stat_get_backend_pid(s.backendid) AS pid,
<row>
<entry role="catalog_table_entry"><para role="column_definition">
- <structfield>datid</structfield> <type>text</type>
+ <structfield>datid</structfield> <type>oid</type>
</para>
<para>
OID of the database to which this backend is connected.
@@ -6467,7 +6467,7 @@ SELECT pg_stat_get_backend_pid(s.backendid) AS pid,
</para>
<para>
OID of the table on which the <command>COPY</command> command is executed.
- It is set to 0 if <command>SELECT</command> query is provided.
+ It is set to 0 if copying from a <command>SELECT</command> query.
</para></entry>
</row>
--
2.17.0
--aM3YZ0Iwxop3KEKx
Content-Type: text/x-diff; charset=us-ascii
Content-Disposition: attachment;
filename="0001-doc-review-COPY-progress-8a4f618e7ae3cb11b0b37d0f06f.patch"
^ permalink raw reply [nested|flat] 54+ messages in thread
* [PATCH] doc review: COPY progress: 8a4f618e7ae3cb11b0b37d0f06f05c8ff905833f
@ 2021-01-07 01:08 Justin Pryzby <[email protected]>
0 siblings, 0 replies; 54+ messages in thread
From: Justin Pryzby @ 2021-01-07 01:08 UTC (permalink / raw)
---
doc/src/sgml/monitoring.sgml | 10 +++++-----
1 file changed, 5 insertions(+), 5 deletions(-)
diff --git a/doc/src/sgml/monitoring.sgml b/doc/src/sgml/monitoring.sgml
index 43fe8ae383..3cdb1aff3c 100644
--- a/doc/src/sgml/monitoring.sgml
+++ b/doc/src/sgml/monitoring.sgml
@@ -6414,9 +6414,9 @@ SELECT pg_stat_get_backend_pid(s.backendid) AS pid,
<para>
Whenever <command>COPY</command> is running, the
<structname>pg_stat_progress_copy</structname> view will contain one row
- for each backend that is currently running <command>COPY</command> command.
- The table bellow describes the information that will be reported and provide
- information how to interpret it.
+ for each backend that is currently running a <command>COPY</command> command.
+ The table below describes the information that will be reported and provides
+ information about how to interpret it.
</para>
<table id="pg-stat-progress-copy-view" xreflabel="pg_stat_progress_copy">
@@ -6445,7 +6445,7 @@ SELECT pg_stat_get_backend_pid(s.backendid) AS pid,
<row>
<entry role="catalog_table_entry"><para role="column_definition">
- <structfield>datid</structfield> <type>text</type>
+ <structfield>datid</structfield> <type>oid</type>
</para>
<para>
OID of the database to which this backend is connected.
@@ -6467,7 +6467,7 @@ SELECT pg_stat_get_backend_pid(s.backendid) AS pid,
</para>
<para>
OID of the table on which the <command>COPY</command> command is executed.
- It is set to 0 if <command>SELECT</command> query is provided.
+ It is set to 0 if copying from a <command>SELECT</command> query.
</para></entry>
</row>
--
2.17.0
--aM3YZ0Iwxop3KEKx--
^ permalink raw reply [nested|flat] 54+ messages in thread
* [PATCH] doc review: COPY progress: 8a4f618e7ae3cb11b0b37d0f06f05c8ff905833f
@ 2021-01-07 01:08 Justin Pryzby <[email protected]>
0 siblings, 0 replies; 54+ messages in thread
From: Justin Pryzby @ 2021-01-07 01:08 UTC (permalink / raw)
---
doc/src/sgml/monitoring.sgml | 10 +++++-----
1 file changed, 5 insertions(+), 5 deletions(-)
diff --git a/doc/src/sgml/monitoring.sgml b/doc/src/sgml/monitoring.sgml
index 43fe8ae383..3cdb1aff3c 100644
--- a/doc/src/sgml/monitoring.sgml
+++ b/doc/src/sgml/monitoring.sgml
@@ -6414,9 +6414,9 @@ SELECT pg_stat_get_backend_pid(s.backendid) AS pid,
<para>
Whenever <command>COPY</command> is running, the
<structname>pg_stat_progress_copy</structname> view will contain one row
- for each backend that is currently running <command>COPY</command> command.
- The table bellow describes the information that will be reported and provide
- information how to interpret it.
+ for each backend that is currently running a <command>COPY</command> command.
+ The table below describes the information that will be reported and provides
+ information about how to interpret it.
</para>
<table id="pg-stat-progress-copy-view" xreflabel="pg_stat_progress_copy">
@@ -6445,7 +6445,7 @@ SELECT pg_stat_get_backend_pid(s.backendid) AS pid,
<row>
<entry role="catalog_table_entry"><para role="column_definition">
- <structfield>datid</structfield> <type>text</type>
+ <structfield>datid</structfield> <type>oid</type>
</para>
<para>
OID of the database to which this backend is connected.
@@ -6467,7 +6467,7 @@ SELECT pg_stat_get_backend_pid(s.backendid) AS pid,
</para>
<para>
OID of the table on which the <command>COPY</command> command is executed.
- It is set to 0 if <command>SELECT</command> query is provided.
+ It is set to 0 if copying from a <command>SELECT</command> query.
</para></entry>
</row>
--
2.17.0
--aM3YZ0Iwxop3KEKx
Content-Type: text/x-diff; charset=us-ascii
Content-Disposition: attachment;
filename="0001-doc-review-COPY-progress-8a4f618e7ae3cb11b0b37d0f06f.patch"
^ permalink raw reply [nested|flat] 54+ messages in thread
* [PATCH] doc review: COPY progress: 8a4f618e7ae3cb11b0b37d0f06f05c8ff905833f
@ 2021-01-07 01:08 Justin Pryzby <[email protected]>
0 siblings, 0 replies; 54+ messages in thread
From: Justin Pryzby @ 2021-01-07 01:08 UTC (permalink / raw)
---
doc/src/sgml/monitoring.sgml | 10 +++++-----
1 file changed, 5 insertions(+), 5 deletions(-)
diff --git a/doc/src/sgml/monitoring.sgml b/doc/src/sgml/monitoring.sgml
index 43fe8ae383..3cdb1aff3c 100644
--- a/doc/src/sgml/monitoring.sgml
+++ b/doc/src/sgml/monitoring.sgml
@@ -6414,9 +6414,9 @@ SELECT pg_stat_get_backend_pid(s.backendid) AS pid,
<para>
Whenever <command>COPY</command> is running, the
<structname>pg_stat_progress_copy</structname> view will contain one row
- for each backend that is currently running <command>COPY</command> command.
- The table bellow describes the information that will be reported and provide
- information how to interpret it.
+ for each backend that is currently running a <command>COPY</command> command.
+ The table below describes the information that will be reported and provides
+ information about how to interpret it.
</para>
<table id="pg-stat-progress-copy-view" xreflabel="pg_stat_progress_copy">
@@ -6445,7 +6445,7 @@ SELECT pg_stat_get_backend_pid(s.backendid) AS pid,
<row>
<entry role="catalog_table_entry"><para role="column_definition">
- <structfield>datid</structfield> <type>text</type>
+ <structfield>datid</structfield> <type>oid</type>
</para>
<para>
OID of the database to which this backend is connected.
@@ -6467,7 +6467,7 @@ SELECT pg_stat_get_backend_pid(s.backendid) AS pid,
</para>
<para>
OID of the table on which the <command>COPY</command> command is executed.
- It is set to 0 if <command>SELECT</command> query is provided.
+ It is set to 0 if copying from a <command>SELECT</command> query.
</para></entry>
</row>
--
2.17.0
--aM3YZ0Iwxop3KEKx--
^ permalink raw reply [nested|flat] 54+ messages in thread
* [PATCH] doc review: COPY progress: 8a4f618e7ae3cb11b0b37d0f06f05c8ff905833f
@ 2021-01-07 01:08 Justin Pryzby <[email protected]>
0 siblings, 0 replies; 54+ messages in thread
From: Justin Pryzby @ 2021-01-07 01:08 UTC (permalink / raw)
---
doc/src/sgml/monitoring.sgml | 10 +++++-----
1 file changed, 5 insertions(+), 5 deletions(-)
diff --git a/doc/src/sgml/monitoring.sgml b/doc/src/sgml/monitoring.sgml
index 43fe8ae383..3cdb1aff3c 100644
--- a/doc/src/sgml/monitoring.sgml
+++ b/doc/src/sgml/monitoring.sgml
@@ -6414,9 +6414,9 @@ SELECT pg_stat_get_backend_pid(s.backendid) AS pid,
<para>
Whenever <command>COPY</command> is running, the
<structname>pg_stat_progress_copy</structname> view will contain one row
- for each backend that is currently running <command>COPY</command> command.
- The table bellow describes the information that will be reported and provide
- information how to interpret it.
+ for each backend that is currently running a <command>COPY</command> command.
+ The table below describes the information that will be reported and provides
+ information about how to interpret it.
</para>
<table id="pg-stat-progress-copy-view" xreflabel="pg_stat_progress_copy">
@@ -6445,7 +6445,7 @@ SELECT pg_stat_get_backend_pid(s.backendid) AS pid,
<row>
<entry role="catalog_table_entry"><para role="column_definition">
- <structfield>datid</structfield> <type>text</type>
+ <structfield>datid</structfield> <type>oid</type>
</para>
<para>
OID of the database to which this backend is connected.
@@ -6467,7 +6467,7 @@ SELECT pg_stat_get_backend_pid(s.backendid) AS pid,
</para>
<para>
OID of the table on which the <command>COPY</command> command is executed.
- It is set to 0 if <command>SELECT</command> query is provided.
+ It is set to 0 if copying from a <command>SELECT</command> query.
</para></entry>
</row>
--
2.17.0
--aM3YZ0Iwxop3KEKx
Content-Type: text/x-diff; charset=us-ascii
Content-Disposition: attachment;
filename="0001-doc-review-COPY-progress-8a4f618e7ae3cb11b0b37d0f06f.patch"
^ permalink raw reply [nested|flat] 54+ messages in thread
* [PATCH] doc review: COPY progress: 8a4f618e7ae3cb11b0b37d0f06f05c8ff905833f
@ 2021-01-07 01:08 Justin Pryzby <[email protected]>
0 siblings, 0 replies; 54+ messages in thread
From: Justin Pryzby @ 2021-01-07 01:08 UTC (permalink / raw)
---
doc/src/sgml/monitoring.sgml | 10 +++++-----
1 file changed, 5 insertions(+), 5 deletions(-)
diff --git a/doc/src/sgml/monitoring.sgml b/doc/src/sgml/monitoring.sgml
index 43fe8ae383..3cdb1aff3c 100644
--- a/doc/src/sgml/monitoring.sgml
+++ b/doc/src/sgml/monitoring.sgml
@@ -6414,9 +6414,9 @@ SELECT pg_stat_get_backend_pid(s.backendid) AS pid,
<para>
Whenever <command>COPY</command> is running, the
<structname>pg_stat_progress_copy</structname> view will contain one row
- for each backend that is currently running <command>COPY</command> command.
- The table bellow describes the information that will be reported and provide
- information how to interpret it.
+ for each backend that is currently running a <command>COPY</command> command.
+ The table below describes the information that will be reported and provides
+ information about how to interpret it.
</para>
<table id="pg-stat-progress-copy-view" xreflabel="pg_stat_progress_copy">
@@ -6445,7 +6445,7 @@ SELECT pg_stat_get_backend_pid(s.backendid) AS pid,
<row>
<entry role="catalog_table_entry"><para role="column_definition">
- <structfield>datid</structfield> <type>text</type>
+ <structfield>datid</structfield> <type>oid</type>
</para>
<para>
OID of the database to which this backend is connected.
@@ -6467,7 +6467,7 @@ SELECT pg_stat_get_backend_pid(s.backendid) AS pid,
</para>
<para>
OID of the table on which the <command>COPY</command> command is executed.
- It is set to 0 if <command>SELECT</command> query is provided.
+ It is set to 0 if copying from a <command>SELECT</command> query.
</para></entry>
</row>
--
2.17.0
--aM3YZ0Iwxop3KEKx--
^ permalink raw reply [nested|flat] 54+ messages in thread
* [PATCH] doc review: COPY progress: 8a4f618e7ae3cb11b0b37d0f06f05c8ff905833f
@ 2021-01-07 01:08 Justin Pryzby <[email protected]>
0 siblings, 0 replies; 54+ messages in thread
From: Justin Pryzby @ 2021-01-07 01:08 UTC (permalink / raw)
---
doc/src/sgml/monitoring.sgml | 10 +++++-----
1 file changed, 5 insertions(+), 5 deletions(-)
diff --git a/doc/src/sgml/monitoring.sgml b/doc/src/sgml/monitoring.sgml
index 43fe8ae383..3cdb1aff3c 100644
--- a/doc/src/sgml/monitoring.sgml
+++ b/doc/src/sgml/monitoring.sgml
@@ -6414,9 +6414,9 @@ SELECT pg_stat_get_backend_pid(s.backendid) AS pid,
<para>
Whenever <command>COPY</command> is running, the
<structname>pg_stat_progress_copy</structname> view will contain one row
- for each backend that is currently running <command>COPY</command> command.
- The table bellow describes the information that will be reported and provide
- information how to interpret it.
+ for each backend that is currently running a <command>COPY</command> command.
+ The table below describes the information that will be reported and provides
+ information about how to interpret it.
</para>
<table id="pg-stat-progress-copy-view" xreflabel="pg_stat_progress_copy">
@@ -6445,7 +6445,7 @@ SELECT pg_stat_get_backend_pid(s.backendid) AS pid,
<row>
<entry role="catalog_table_entry"><para role="column_definition">
- <structfield>datid</structfield> <type>text</type>
+ <structfield>datid</structfield> <type>oid</type>
</para>
<para>
OID of the database to which this backend is connected.
@@ -6467,7 +6467,7 @@ SELECT pg_stat_get_backend_pid(s.backendid) AS pid,
</para>
<para>
OID of the table on which the <command>COPY</command> command is executed.
- It is set to 0 if <command>SELECT</command> query is provided.
+ It is set to 0 if copying from a <command>SELECT</command> query.
</para></entry>
</row>
--
2.17.0
--aM3YZ0Iwxop3KEKx
Content-Type: text/x-diff; charset=us-ascii
Content-Disposition: attachment;
filename="0001-doc-review-COPY-progress-8a4f618e7ae3cb11b0b37d0f06f.patch"
^ permalink raw reply [nested|flat] 54+ messages in thread
* [PATCH] doc review: COPY progress: 8a4f618e7ae3cb11b0b37d0f06f05c8ff905833f
@ 2021-01-07 01:08 Justin Pryzby <[email protected]>
0 siblings, 0 replies; 54+ messages in thread
From: Justin Pryzby @ 2021-01-07 01:08 UTC (permalink / raw)
---
doc/src/sgml/monitoring.sgml | 10 +++++-----
1 file changed, 5 insertions(+), 5 deletions(-)
diff --git a/doc/src/sgml/monitoring.sgml b/doc/src/sgml/monitoring.sgml
index 43fe8ae383..3cdb1aff3c 100644
--- a/doc/src/sgml/monitoring.sgml
+++ b/doc/src/sgml/monitoring.sgml
@@ -6414,9 +6414,9 @@ SELECT pg_stat_get_backend_pid(s.backendid) AS pid,
<para>
Whenever <command>COPY</command> is running, the
<structname>pg_stat_progress_copy</structname> view will contain one row
- for each backend that is currently running <command>COPY</command> command.
- The table bellow describes the information that will be reported and provide
- information how to interpret it.
+ for each backend that is currently running a <command>COPY</command> command.
+ The table below describes the information that will be reported and provides
+ information about how to interpret it.
</para>
<table id="pg-stat-progress-copy-view" xreflabel="pg_stat_progress_copy">
@@ -6445,7 +6445,7 @@ SELECT pg_stat_get_backend_pid(s.backendid) AS pid,
<row>
<entry role="catalog_table_entry"><para role="column_definition">
- <structfield>datid</structfield> <type>text</type>
+ <structfield>datid</structfield> <type>oid</type>
</para>
<para>
OID of the database to which this backend is connected.
@@ -6467,7 +6467,7 @@ SELECT pg_stat_get_backend_pid(s.backendid) AS pid,
</para>
<para>
OID of the table on which the <command>COPY</command> command is executed.
- It is set to 0 if <command>SELECT</command> query is provided.
+ It is set to 0 if copying from a <command>SELECT</command> query.
</para></entry>
</row>
--
2.17.0
--aM3YZ0Iwxop3KEKx--
^ permalink raw reply [nested|flat] 54+ messages in thread
* [PATCH] doc review: COPY progress: 8a4f618e7ae3cb11b0b37d0f06f05c8ff905833f
@ 2021-01-07 01:08 Justin Pryzby <[email protected]>
0 siblings, 0 replies; 54+ messages in thread
From: Justin Pryzby @ 2021-01-07 01:08 UTC (permalink / raw)
---
doc/src/sgml/monitoring.sgml | 10 +++++-----
1 file changed, 5 insertions(+), 5 deletions(-)
diff --git a/doc/src/sgml/monitoring.sgml b/doc/src/sgml/monitoring.sgml
index 43fe8ae383..3cdb1aff3c 100644
--- a/doc/src/sgml/monitoring.sgml
+++ b/doc/src/sgml/monitoring.sgml
@@ -6414,9 +6414,9 @@ SELECT pg_stat_get_backend_pid(s.backendid) AS pid,
<para>
Whenever <command>COPY</command> is running, the
<structname>pg_stat_progress_copy</structname> view will contain one row
- for each backend that is currently running <command>COPY</command> command.
- The table bellow describes the information that will be reported and provide
- information how to interpret it.
+ for each backend that is currently running a <command>COPY</command> command.
+ The table below describes the information that will be reported and provides
+ information about how to interpret it.
</para>
<table id="pg-stat-progress-copy-view" xreflabel="pg_stat_progress_copy">
@@ -6445,7 +6445,7 @@ SELECT pg_stat_get_backend_pid(s.backendid) AS pid,
<row>
<entry role="catalog_table_entry"><para role="column_definition">
- <structfield>datid</structfield> <type>text</type>
+ <structfield>datid</structfield> <type>oid</type>
</para>
<para>
OID of the database to which this backend is connected.
@@ -6467,7 +6467,7 @@ SELECT pg_stat_get_backend_pid(s.backendid) AS pid,
</para>
<para>
OID of the table on which the <command>COPY</command> command is executed.
- It is set to 0 if <command>SELECT</command> query is provided.
+ It is set to 0 if copying from a <command>SELECT</command> query.
</para></entry>
</row>
--
2.17.0
--aM3YZ0Iwxop3KEKx
Content-Type: text/x-diff; charset=us-ascii
Content-Disposition: attachment;
filename="0001-doc-review-COPY-progress-8a4f618e7ae3cb11b0b37d0f06f.patch"
^ permalink raw reply [nested|flat] 54+ messages in thread
* [PATCH] doc review: COPY progress: 8a4f618e7ae3cb11b0b37d0f06f05c8ff905833f
@ 2021-01-07 01:08 Justin Pryzby <[email protected]>
0 siblings, 0 replies; 54+ messages in thread
From: Justin Pryzby @ 2021-01-07 01:08 UTC (permalink / raw)
---
doc/src/sgml/monitoring.sgml | 10 +++++-----
1 file changed, 5 insertions(+), 5 deletions(-)
diff --git a/doc/src/sgml/monitoring.sgml b/doc/src/sgml/monitoring.sgml
index 43fe8ae383..3cdb1aff3c 100644
--- a/doc/src/sgml/monitoring.sgml
+++ b/doc/src/sgml/monitoring.sgml
@@ -6414,9 +6414,9 @@ SELECT pg_stat_get_backend_pid(s.backendid) AS pid,
<para>
Whenever <command>COPY</command> is running, the
<structname>pg_stat_progress_copy</structname> view will contain one row
- for each backend that is currently running <command>COPY</command> command.
- The table bellow describes the information that will be reported and provide
- information how to interpret it.
+ for each backend that is currently running a <command>COPY</command> command.
+ The table below describes the information that will be reported and provides
+ information about how to interpret it.
</para>
<table id="pg-stat-progress-copy-view" xreflabel="pg_stat_progress_copy">
@@ -6445,7 +6445,7 @@ SELECT pg_stat_get_backend_pid(s.backendid) AS pid,
<row>
<entry role="catalog_table_entry"><para role="column_definition">
- <structfield>datid</structfield> <type>text</type>
+ <structfield>datid</structfield> <type>oid</type>
</para>
<para>
OID of the database to which this backend is connected.
@@ -6467,7 +6467,7 @@ SELECT pg_stat_get_backend_pid(s.backendid) AS pid,
</para>
<para>
OID of the table on which the <command>COPY</command> command is executed.
- It is set to 0 if <command>SELECT</command> query is provided.
+ It is set to 0 if copying from a <command>SELECT</command> query.
</para></entry>
</row>
--
2.17.0
--aM3YZ0Iwxop3KEKx--
^ permalink raw reply [nested|flat] 54+ messages in thread
* [PATCH] doc review: COPY progress: 8a4f618e7ae3cb11b0b37d0f06f05c8ff905833f
@ 2021-01-07 01:08 Justin Pryzby <[email protected]>
0 siblings, 0 replies; 54+ messages in thread
From: Justin Pryzby @ 2021-01-07 01:08 UTC (permalink / raw)
---
doc/src/sgml/monitoring.sgml | 10 +++++-----
1 file changed, 5 insertions(+), 5 deletions(-)
diff --git a/doc/src/sgml/monitoring.sgml b/doc/src/sgml/monitoring.sgml
index 43fe8ae383..3cdb1aff3c 100644
--- a/doc/src/sgml/monitoring.sgml
+++ b/doc/src/sgml/monitoring.sgml
@@ -6414,9 +6414,9 @@ SELECT pg_stat_get_backend_pid(s.backendid) AS pid,
<para>
Whenever <command>COPY</command> is running, the
<structname>pg_stat_progress_copy</structname> view will contain one row
- for each backend that is currently running <command>COPY</command> command.
- The table bellow describes the information that will be reported and provide
- information how to interpret it.
+ for each backend that is currently running a <command>COPY</command> command.
+ The table below describes the information that will be reported and provides
+ information about how to interpret it.
</para>
<table id="pg-stat-progress-copy-view" xreflabel="pg_stat_progress_copy">
@@ -6445,7 +6445,7 @@ SELECT pg_stat_get_backend_pid(s.backendid) AS pid,
<row>
<entry role="catalog_table_entry"><para role="column_definition">
- <structfield>datid</structfield> <type>text</type>
+ <structfield>datid</structfield> <type>oid</type>
</para>
<para>
OID of the database to which this backend is connected.
@@ -6467,7 +6467,7 @@ SELECT pg_stat_get_backend_pid(s.backendid) AS pid,
</para>
<para>
OID of the table on which the <command>COPY</command> command is executed.
- It is set to 0 if <command>SELECT</command> query is provided.
+ It is set to 0 if copying from a <command>SELECT</command> query.
</para></entry>
</row>
--
2.17.0
--aM3YZ0Iwxop3KEKx
Content-Type: text/x-diff; charset=us-ascii
Content-Disposition: attachment;
filename="0001-doc-review-COPY-progress-8a4f618e7ae3cb11b0b37d0f06f.patch"
^ permalink raw reply [nested|flat] 54+ messages in thread
* [PATCH] doc review: COPY progress: 8a4f618e7ae3cb11b0b37d0f06f05c8ff905833f
@ 2021-01-07 01:08 Justin Pryzby <[email protected]>
0 siblings, 0 replies; 54+ messages in thread
From: Justin Pryzby @ 2021-01-07 01:08 UTC (permalink / raw)
---
doc/src/sgml/monitoring.sgml | 10 +++++-----
1 file changed, 5 insertions(+), 5 deletions(-)
diff --git a/doc/src/sgml/monitoring.sgml b/doc/src/sgml/monitoring.sgml
index 43fe8ae383..3cdb1aff3c 100644
--- a/doc/src/sgml/monitoring.sgml
+++ b/doc/src/sgml/monitoring.sgml
@@ -6414,9 +6414,9 @@ SELECT pg_stat_get_backend_pid(s.backendid) AS pid,
<para>
Whenever <command>COPY</command> is running, the
<structname>pg_stat_progress_copy</structname> view will contain one row
- for each backend that is currently running <command>COPY</command> command.
- The table bellow describes the information that will be reported and provide
- information how to interpret it.
+ for each backend that is currently running a <command>COPY</command> command.
+ The table below describes the information that will be reported and provides
+ information about how to interpret it.
</para>
<table id="pg-stat-progress-copy-view" xreflabel="pg_stat_progress_copy">
@@ -6445,7 +6445,7 @@ SELECT pg_stat_get_backend_pid(s.backendid) AS pid,
<row>
<entry role="catalog_table_entry"><para role="column_definition">
- <structfield>datid</structfield> <type>text</type>
+ <structfield>datid</structfield> <type>oid</type>
</para>
<para>
OID of the database to which this backend is connected.
@@ -6467,7 +6467,7 @@ SELECT pg_stat_get_backend_pid(s.backendid) AS pid,
</para>
<para>
OID of the table on which the <command>COPY</command> command is executed.
- It is set to 0 if <command>SELECT</command> query is provided.
+ It is set to 0 if copying from a <command>SELECT</command> query.
</para></entry>
</row>
--
2.17.0
--aM3YZ0Iwxop3KEKx--
^ permalink raw reply [nested|flat] 54+ messages in thread
* [PATCH] doc review: COPY progress: 8a4f618e7ae3cb11b0b37d0f06f05c8ff905833f
@ 2021-01-07 01:08 Justin Pryzby <[email protected]>
0 siblings, 0 replies; 54+ messages in thread
From: Justin Pryzby @ 2021-01-07 01:08 UTC (permalink / raw)
---
doc/src/sgml/monitoring.sgml | 10 +++++-----
1 file changed, 5 insertions(+), 5 deletions(-)
diff --git a/doc/src/sgml/monitoring.sgml b/doc/src/sgml/monitoring.sgml
index 43fe8ae383..3cdb1aff3c 100644
--- a/doc/src/sgml/monitoring.sgml
+++ b/doc/src/sgml/monitoring.sgml
@@ -6414,9 +6414,9 @@ SELECT pg_stat_get_backend_pid(s.backendid) AS pid,
<para>
Whenever <command>COPY</command> is running, the
<structname>pg_stat_progress_copy</structname> view will contain one row
- for each backend that is currently running <command>COPY</command> command.
- The table bellow describes the information that will be reported and provide
- information how to interpret it.
+ for each backend that is currently running a <command>COPY</command> command.
+ The table below describes the information that will be reported and provides
+ information about how to interpret it.
</para>
<table id="pg-stat-progress-copy-view" xreflabel="pg_stat_progress_copy">
@@ -6445,7 +6445,7 @@ SELECT pg_stat_get_backend_pid(s.backendid) AS pid,
<row>
<entry role="catalog_table_entry"><para role="column_definition">
- <structfield>datid</structfield> <type>text</type>
+ <structfield>datid</structfield> <type>oid</type>
</para>
<para>
OID of the database to which this backend is connected.
@@ -6467,7 +6467,7 @@ SELECT pg_stat_get_backend_pid(s.backendid) AS pid,
</para>
<para>
OID of the table on which the <command>COPY</command> command is executed.
- It is set to 0 if <command>SELECT</command> query is provided.
+ It is set to 0 if copying from a <command>SELECT</command> query.
</para></entry>
</row>
--
2.17.0
--aM3YZ0Iwxop3KEKx
Content-Type: text/x-diff; charset=us-ascii
Content-Disposition: attachment;
filename="0001-doc-review-COPY-progress-8a4f618e7ae3cb11b0b37d0f06f.patch"
^ permalink raw reply [nested|flat] 54+ messages in thread
* [PATCH] doc review: COPY progress: 8a4f618e7ae3cb11b0b37d0f06f05c8ff905833f
@ 2021-01-07 01:08 Justin Pryzby <[email protected]>
0 siblings, 0 replies; 54+ messages in thread
From: Justin Pryzby @ 2021-01-07 01:08 UTC (permalink / raw)
---
doc/src/sgml/monitoring.sgml | 10 +++++-----
1 file changed, 5 insertions(+), 5 deletions(-)
diff --git a/doc/src/sgml/monitoring.sgml b/doc/src/sgml/monitoring.sgml
index 43fe8ae383..3cdb1aff3c 100644
--- a/doc/src/sgml/monitoring.sgml
+++ b/doc/src/sgml/monitoring.sgml
@@ -6414,9 +6414,9 @@ SELECT pg_stat_get_backend_pid(s.backendid) AS pid,
<para>
Whenever <command>COPY</command> is running, the
<structname>pg_stat_progress_copy</structname> view will contain one row
- for each backend that is currently running <command>COPY</command> command.
- The table bellow describes the information that will be reported and provide
- information how to interpret it.
+ for each backend that is currently running a <command>COPY</command> command.
+ The table below describes the information that will be reported and provides
+ information about how to interpret it.
</para>
<table id="pg-stat-progress-copy-view" xreflabel="pg_stat_progress_copy">
@@ -6445,7 +6445,7 @@ SELECT pg_stat_get_backend_pid(s.backendid) AS pid,
<row>
<entry role="catalog_table_entry"><para role="column_definition">
- <structfield>datid</structfield> <type>text</type>
+ <structfield>datid</structfield> <type>oid</type>
</para>
<para>
OID of the database to which this backend is connected.
@@ -6467,7 +6467,7 @@ SELECT pg_stat_get_backend_pid(s.backendid) AS pid,
</para>
<para>
OID of the table on which the <command>COPY</command> command is executed.
- It is set to 0 if <command>SELECT</command> query is provided.
+ It is set to 0 if copying from a <command>SELECT</command> query.
</para></entry>
</row>
--
2.17.0
--aM3YZ0Iwxop3KEKx--
^ permalink raw reply [nested|flat] 54+ messages in thread
* [PATCH] doc review: COPY progress: 8a4f618e7ae3cb11b0b37d0f06f05c8ff905833f
@ 2021-01-07 01:08 Justin Pryzby <[email protected]>
0 siblings, 0 replies; 54+ messages in thread
From: Justin Pryzby @ 2021-01-07 01:08 UTC (permalink / raw)
---
doc/src/sgml/monitoring.sgml | 10 +++++-----
1 file changed, 5 insertions(+), 5 deletions(-)
diff --git a/doc/src/sgml/monitoring.sgml b/doc/src/sgml/monitoring.sgml
index 43fe8ae383..3cdb1aff3c 100644
--- a/doc/src/sgml/monitoring.sgml
+++ b/doc/src/sgml/monitoring.sgml
@@ -6414,9 +6414,9 @@ SELECT pg_stat_get_backend_pid(s.backendid) AS pid,
<para>
Whenever <command>COPY</command> is running, the
<structname>pg_stat_progress_copy</structname> view will contain one row
- for each backend that is currently running <command>COPY</command> command.
- The table bellow describes the information that will be reported and provide
- information how to interpret it.
+ for each backend that is currently running a <command>COPY</command> command.
+ The table below describes the information that will be reported and provides
+ information about how to interpret it.
</para>
<table id="pg-stat-progress-copy-view" xreflabel="pg_stat_progress_copy">
@@ -6445,7 +6445,7 @@ SELECT pg_stat_get_backend_pid(s.backendid) AS pid,
<row>
<entry role="catalog_table_entry"><para role="column_definition">
- <structfield>datid</structfield> <type>text</type>
+ <structfield>datid</structfield> <type>oid</type>
</para>
<para>
OID of the database to which this backend is connected.
@@ -6467,7 +6467,7 @@ SELECT pg_stat_get_backend_pid(s.backendid) AS pid,
</para>
<para>
OID of the table on which the <command>COPY</command> command is executed.
- It is set to 0 if <command>SELECT</command> query is provided.
+ It is set to 0 if copying from a <command>SELECT</command> query.
</para></entry>
</row>
--
2.17.0
--aM3YZ0Iwxop3KEKx
Content-Type: text/x-diff; charset=us-ascii
Content-Disposition: attachment;
filename="0001-doc-review-COPY-progress-8a4f618e7ae3cb11b0b37d0f06f.patch"
^ permalink raw reply [nested|flat] 54+ messages in thread
* [PATCH] doc review: COPY progress: 8a4f618e7ae3cb11b0b37d0f06f05c8ff905833f
@ 2021-01-07 01:08 Justin Pryzby <[email protected]>
0 siblings, 0 replies; 54+ messages in thread
From: Justin Pryzby @ 2021-01-07 01:08 UTC (permalink / raw)
---
doc/src/sgml/monitoring.sgml | 10 +++++-----
1 file changed, 5 insertions(+), 5 deletions(-)
diff --git a/doc/src/sgml/monitoring.sgml b/doc/src/sgml/monitoring.sgml
index 43fe8ae383..3cdb1aff3c 100644
--- a/doc/src/sgml/monitoring.sgml
+++ b/doc/src/sgml/monitoring.sgml
@@ -6414,9 +6414,9 @@ SELECT pg_stat_get_backend_pid(s.backendid) AS pid,
<para>
Whenever <command>COPY</command> is running, the
<structname>pg_stat_progress_copy</structname> view will contain one row
- for each backend that is currently running <command>COPY</command> command.
- The table bellow describes the information that will be reported and provide
- information how to interpret it.
+ for each backend that is currently running a <command>COPY</command> command.
+ The table below describes the information that will be reported and provides
+ information about how to interpret it.
</para>
<table id="pg-stat-progress-copy-view" xreflabel="pg_stat_progress_copy">
@@ -6445,7 +6445,7 @@ SELECT pg_stat_get_backend_pid(s.backendid) AS pid,
<row>
<entry role="catalog_table_entry"><para role="column_definition">
- <structfield>datid</structfield> <type>text</type>
+ <structfield>datid</structfield> <type>oid</type>
</para>
<para>
OID of the database to which this backend is connected.
@@ -6467,7 +6467,7 @@ SELECT pg_stat_get_backend_pid(s.backendid) AS pid,
</para>
<para>
OID of the table on which the <command>COPY</command> command is executed.
- It is set to 0 if <command>SELECT</command> query is provided.
+ It is set to 0 if copying from a <command>SELECT</command> query.
</para></entry>
</row>
--
2.17.0
--aM3YZ0Iwxop3KEKx--
^ permalink raw reply [nested|flat] 54+ messages in thread
* [PATCH] doc review: COPY progress: 8a4f618e7ae3cb11b0b37d0f06f05c8ff905833f
@ 2021-01-07 01:08 Justin Pryzby <[email protected]>
0 siblings, 0 replies; 54+ messages in thread
From: Justin Pryzby @ 2021-01-07 01:08 UTC (permalink / raw)
---
doc/src/sgml/monitoring.sgml | 10 +++++-----
1 file changed, 5 insertions(+), 5 deletions(-)
diff --git a/doc/src/sgml/monitoring.sgml b/doc/src/sgml/monitoring.sgml
index 43fe8ae383..3cdb1aff3c 100644
--- a/doc/src/sgml/monitoring.sgml
+++ b/doc/src/sgml/monitoring.sgml
@@ -6414,9 +6414,9 @@ SELECT pg_stat_get_backend_pid(s.backendid) AS pid,
<para>
Whenever <command>COPY</command> is running, the
<structname>pg_stat_progress_copy</structname> view will contain one row
- for each backend that is currently running <command>COPY</command> command.
- The table bellow describes the information that will be reported and provide
- information how to interpret it.
+ for each backend that is currently running a <command>COPY</command> command.
+ The table below describes the information that will be reported and provides
+ information about how to interpret it.
</para>
<table id="pg-stat-progress-copy-view" xreflabel="pg_stat_progress_copy">
@@ -6445,7 +6445,7 @@ SELECT pg_stat_get_backend_pid(s.backendid) AS pid,
<row>
<entry role="catalog_table_entry"><para role="column_definition">
- <structfield>datid</structfield> <type>text</type>
+ <structfield>datid</structfield> <type>oid</type>
</para>
<para>
OID of the database to which this backend is connected.
@@ -6467,7 +6467,7 @@ SELECT pg_stat_get_backend_pid(s.backendid) AS pid,
</para>
<para>
OID of the table on which the <command>COPY</command> command is executed.
- It is set to 0 if <command>SELECT</command> query is provided.
+ It is set to 0 if copying from a <command>SELECT</command> query.
</para></entry>
</row>
--
2.17.0
--aM3YZ0Iwxop3KEKx--
^ permalink raw reply [nested|flat] 54+ messages in thread
* [PATCH] doc review: COPY progress: 8a4f618e7ae3cb11b0b37d0f06f05c8ff905833f
@ 2021-01-07 01:08 Justin Pryzby <[email protected]>
0 siblings, 0 replies; 54+ messages in thread
From: Justin Pryzby @ 2021-01-07 01:08 UTC (permalink / raw)
---
doc/src/sgml/monitoring.sgml | 10 +++++-----
1 file changed, 5 insertions(+), 5 deletions(-)
diff --git a/doc/src/sgml/monitoring.sgml b/doc/src/sgml/monitoring.sgml
index 43fe8ae383..3cdb1aff3c 100644
--- a/doc/src/sgml/monitoring.sgml
+++ b/doc/src/sgml/monitoring.sgml
@@ -6414,9 +6414,9 @@ SELECT pg_stat_get_backend_pid(s.backendid) AS pid,
<para>
Whenever <command>COPY</command> is running, the
<structname>pg_stat_progress_copy</structname> view will contain one row
- for each backend that is currently running <command>COPY</command> command.
- The table bellow describes the information that will be reported and provide
- information how to interpret it.
+ for each backend that is currently running a <command>COPY</command> command.
+ The table below describes the information that will be reported and provides
+ information about how to interpret it.
</para>
<table id="pg-stat-progress-copy-view" xreflabel="pg_stat_progress_copy">
@@ -6445,7 +6445,7 @@ SELECT pg_stat_get_backend_pid(s.backendid) AS pid,
<row>
<entry role="catalog_table_entry"><para role="column_definition">
- <structfield>datid</structfield> <type>text</type>
+ <structfield>datid</structfield> <type>oid</type>
</para>
<para>
OID of the database to which this backend is connected.
@@ -6467,7 +6467,7 @@ SELECT pg_stat_get_backend_pid(s.backendid) AS pid,
</para>
<para>
OID of the table on which the <command>COPY</command> command is executed.
- It is set to 0 if <command>SELECT</command> query is provided.
+ It is set to 0 if copying from a <command>SELECT</command> query.
</para></entry>
</row>
--
2.17.0
--aM3YZ0Iwxop3KEKx
Content-Type: text/x-diff; charset=us-ascii
Content-Disposition: attachment;
filename="0001-doc-review-COPY-progress-8a4f618e7ae3cb11b0b37d0f06f.patch"
^ permalink raw reply [nested|flat] 54+ messages in thread
* [PATCH] doc review: COPY progress: 8a4f618e7ae3cb11b0b37d0f06f05c8ff905833f
@ 2021-01-07 01:08 Justin Pryzby <[email protected]>
0 siblings, 0 replies; 54+ messages in thread
From: Justin Pryzby @ 2021-01-07 01:08 UTC (permalink / raw)
---
doc/src/sgml/monitoring.sgml | 10 +++++-----
1 file changed, 5 insertions(+), 5 deletions(-)
diff --git a/doc/src/sgml/monitoring.sgml b/doc/src/sgml/monitoring.sgml
index 43fe8ae383..3cdb1aff3c 100644
--- a/doc/src/sgml/monitoring.sgml
+++ b/doc/src/sgml/monitoring.sgml
@@ -6414,9 +6414,9 @@ SELECT pg_stat_get_backend_pid(s.backendid) AS pid,
<para>
Whenever <command>COPY</command> is running, the
<structname>pg_stat_progress_copy</structname> view will contain one row
- for each backend that is currently running <command>COPY</command> command.
- The table bellow describes the information that will be reported and provide
- information how to interpret it.
+ for each backend that is currently running a <command>COPY</command> command.
+ The table below describes the information that will be reported and provides
+ information about how to interpret it.
</para>
<table id="pg-stat-progress-copy-view" xreflabel="pg_stat_progress_copy">
@@ -6445,7 +6445,7 @@ SELECT pg_stat_get_backend_pid(s.backendid) AS pid,
<row>
<entry role="catalog_table_entry"><para role="column_definition">
- <structfield>datid</structfield> <type>text</type>
+ <structfield>datid</structfield> <type>oid</type>
</para>
<para>
OID of the database to which this backend is connected.
@@ -6467,7 +6467,7 @@ SELECT pg_stat_get_backend_pid(s.backendid) AS pid,
</para>
<para>
OID of the table on which the <command>COPY</command> command is executed.
- It is set to 0 if <command>SELECT</command> query is provided.
+ It is set to 0 if copying from a <command>SELECT</command> query.
</para></entry>
</row>
--
2.17.0
--aM3YZ0Iwxop3KEKx--
^ permalink raw reply [nested|flat] 54+ messages in thread
* [PATCH] doc review: COPY progress: 8a4f618e7ae3cb11b0b37d0f06f05c8ff905833f
@ 2021-01-07 01:08 Justin Pryzby <[email protected]>
0 siblings, 0 replies; 54+ messages in thread
From: Justin Pryzby @ 2021-01-07 01:08 UTC (permalink / raw)
---
doc/src/sgml/monitoring.sgml | 10 +++++-----
1 file changed, 5 insertions(+), 5 deletions(-)
diff --git a/doc/src/sgml/monitoring.sgml b/doc/src/sgml/monitoring.sgml
index 43fe8ae383..3cdb1aff3c 100644
--- a/doc/src/sgml/monitoring.sgml
+++ b/doc/src/sgml/monitoring.sgml
@@ -6414,9 +6414,9 @@ SELECT pg_stat_get_backend_pid(s.backendid) AS pid,
<para>
Whenever <command>COPY</command> is running, the
<structname>pg_stat_progress_copy</structname> view will contain one row
- for each backend that is currently running <command>COPY</command> command.
- The table bellow describes the information that will be reported and provide
- information how to interpret it.
+ for each backend that is currently running a <command>COPY</command> command.
+ The table below describes the information that will be reported and provides
+ information about how to interpret it.
</para>
<table id="pg-stat-progress-copy-view" xreflabel="pg_stat_progress_copy">
@@ -6445,7 +6445,7 @@ SELECT pg_stat_get_backend_pid(s.backendid) AS pid,
<row>
<entry role="catalog_table_entry"><para role="column_definition">
- <structfield>datid</structfield> <type>text</type>
+ <structfield>datid</structfield> <type>oid</type>
</para>
<para>
OID of the database to which this backend is connected.
@@ -6467,7 +6467,7 @@ SELECT pg_stat_get_backend_pid(s.backendid) AS pid,
</para>
<para>
OID of the table on which the <command>COPY</command> command is executed.
- It is set to 0 if <command>SELECT</command> query is provided.
+ It is set to 0 if copying from a <command>SELECT</command> query.
</para></entry>
</row>
--
2.17.0
--aM3YZ0Iwxop3KEKx
Content-Type: text/x-diff; charset=us-ascii
Content-Disposition: attachment;
filename="0001-doc-review-COPY-progress-8a4f618e7ae3cb11b0b37d0f06f.patch"
^ permalink raw reply [nested|flat] 54+ messages in thread
* [PATCH] doc review: COPY progress: 8a4f618e7ae3cb11b0b37d0f06f05c8ff905833f
@ 2021-01-07 01:08 Justin Pryzby <[email protected]>
0 siblings, 0 replies; 54+ messages in thread
From: Justin Pryzby @ 2021-01-07 01:08 UTC (permalink / raw)
---
doc/src/sgml/monitoring.sgml | 10 +++++-----
1 file changed, 5 insertions(+), 5 deletions(-)
diff --git a/doc/src/sgml/monitoring.sgml b/doc/src/sgml/monitoring.sgml
index 43fe8ae383..3cdb1aff3c 100644
--- a/doc/src/sgml/monitoring.sgml
+++ b/doc/src/sgml/monitoring.sgml
@@ -6414,9 +6414,9 @@ SELECT pg_stat_get_backend_pid(s.backendid) AS pid,
<para>
Whenever <command>COPY</command> is running, the
<structname>pg_stat_progress_copy</structname> view will contain one row
- for each backend that is currently running <command>COPY</command> command.
- The table bellow describes the information that will be reported and provide
- information how to interpret it.
+ for each backend that is currently running a <command>COPY</command> command.
+ The table below describes the information that will be reported and provides
+ information about how to interpret it.
</para>
<table id="pg-stat-progress-copy-view" xreflabel="pg_stat_progress_copy">
@@ -6445,7 +6445,7 @@ SELECT pg_stat_get_backend_pid(s.backendid) AS pid,
<row>
<entry role="catalog_table_entry"><para role="column_definition">
- <structfield>datid</structfield> <type>text</type>
+ <structfield>datid</structfield> <type>oid</type>
</para>
<para>
OID of the database to which this backend is connected.
@@ -6467,7 +6467,7 @@ SELECT pg_stat_get_backend_pid(s.backendid) AS pid,
</para>
<para>
OID of the table on which the <command>COPY</command> command is executed.
- It is set to 0 if <command>SELECT</command> query is provided.
+ It is set to 0 if copying from a <command>SELECT</command> query.
</para></entry>
</row>
--
2.17.0
--aM3YZ0Iwxop3KEKx--
^ permalink raw reply [nested|flat] 54+ messages in thread
* [PATCH] doc review: COPY progress: 8a4f618e7ae3cb11b0b37d0f06f05c8ff905833f
@ 2021-01-07 01:08 Justin Pryzby <[email protected]>
0 siblings, 0 replies; 54+ messages in thread
From: Justin Pryzby @ 2021-01-07 01:08 UTC (permalink / raw)
---
doc/src/sgml/monitoring.sgml | 10 +++++-----
1 file changed, 5 insertions(+), 5 deletions(-)
diff --git a/doc/src/sgml/monitoring.sgml b/doc/src/sgml/monitoring.sgml
index 43fe8ae383..3cdb1aff3c 100644
--- a/doc/src/sgml/monitoring.sgml
+++ b/doc/src/sgml/monitoring.sgml
@@ -6414,9 +6414,9 @@ SELECT pg_stat_get_backend_pid(s.backendid) AS pid,
<para>
Whenever <command>COPY</command> is running, the
<structname>pg_stat_progress_copy</structname> view will contain one row
- for each backend that is currently running <command>COPY</command> command.
- The table bellow describes the information that will be reported and provide
- information how to interpret it.
+ for each backend that is currently running a <command>COPY</command> command.
+ The table below describes the information that will be reported and provides
+ information about how to interpret it.
</para>
<table id="pg-stat-progress-copy-view" xreflabel="pg_stat_progress_copy">
@@ -6445,7 +6445,7 @@ SELECT pg_stat_get_backend_pid(s.backendid) AS pid,
<row>
<entry role="catalog_table_entry"><para role="column_definition">
- <structfield>datid</structfield> <type>text</type>
+ <structfield>datid</structfield> <type>oid</type>
</para>
<para>
OID of the database to which this backend is connected.
@@ -6467,7 +6467,7 @@ SELECT pg_stat_get_backend_pid(s.backendid) AS pid,
</para>
<para>
OID of the table on which the <command>COPY</command> command is executed.
- It is set to 0 if <command>SELECT</command> query is provided.
+ It is set to 0 if copying from a <command>SELECT</command> query.
</para></entry>
</row>
--
2.17.0
--aM3YZ0Iwxop3KEKx
Content-Type: text/x-diff; charset=us-ascii
Content-Disposition: attachment;
filename="0001-doc-review-COPY-progress-8a4f618e7ae3cb11b0b37d0f06f.patch"
^ permalink raw reply [nested|flat] 54+ messages in thread
* [PATCH] doc review: COPY progress: 8a4f618e7ae3cb11b0b37d0f06f05c8ff905833f
@ 2021-01-07 01:08 Justin Pryzby <[email protected]>
0 siblings, 0 replies; 54+ messages in thread
From: Justin Pryzby @ 2021-01-07 01:08 UTC (permalink / raw)
---
doc/src/sgml/monitoring.sgml | 10 +++++-----
1 file changed, 5 insertions(+), 5 deletions(-)
diff --git a/doc/src/sgml/monitoring.sgml b/doc/src/sgml/monitoring.sgml
index 43fe8ae383..3cdb1aff3c 100644
--- a/doc/src/sgml/monitoring.sgml
+++ b/doc/src/sgml/monitoring.sgml
@@ -6414,9 +6414,9 @@ SELECT pg_stat_get_backend_pid(s.backendid) AS pid,
<para>
Whenever <command>COPY</command> is running, the
<structname>pg_stat_progress_copy</structname> view will contain one row
- for each backend that is currently running <command>COPY</command> command.
- The table bellow describes the information that will be reported and provide
- information how to interpret it.
+ for each backend that is currently running a <command>COPY</command> command.
+ The table below describes the information that will be reported and provides
+ information about how to interpret it.
</para>
<table id="pg-stat-progress-copy-view" xreflabel="pg_stat_progress_copy">
@@ -6445,7 +6445,7 @@ SELECT pg_stat_get_backend_pid(s.backendid) AS pid,
<row>
<entry role="catalog_table_entry"><para role="column_definition">
- <structfield>datid</structfield> <type>text</type>
+ <structfield>datid</structfield> <type>oid</type>
</para>
<para>
OID of the database to which this backend is connected.
@@ -6467,7 +6467,7 @@ SELECT pg_stat_get_backend_pid(s.backendid) AS pid,
</para>
<para>
OID of the table on which the <command>COPY</command> command is executed.
- It is set to 0 if <command>SELECT</command> query is provided.
+ It is set to 0 if copying from a <command>SELECT</command> query.
</para></entry>
</row>
--
2.17.0
--aM3YZ0Iwxop3KEKx--
^ permalink raw reply [nested|flat] 54+ messages in thread
* [PATCH] doc review: COPY progress: 8a4f618e7ae3cb11b0b37d0f06f05c8ff905833f
@ 2021-01-07 01:08 Justin Pryzby <[email protected]>
0 siblings, 0 replies; 54+ messages in thread
From: Justin Pryzby @ 2021-01-07 01:08 UTC (permalink / raw)
---
doc/src/sgml/monitoring.sgml | 10 +++++-----
1 file changed, 5 insertions(+), 5 deletions(-)
diff --git a/doc/src/sgml/monitoring.sgml b/doc/src/sgml/monitoring.sgml
index 43fe8ae383..3cdb1aff3c 100644
--- a/doc/src/sgml/monitoring.sgml
+++ b/doc/src/sgml/monitoring.sgml
@@ -6414,9 +6414,9 @@ SELECT pg_stat_get_backend_pid(s.backendid) AS pid,
<para>
Whenever <command>COPY</command> is running, the
<structname>pg_stat_progress_copy</structname> view will contain one row
- for each backend that is currently running <command>COPY</command> command.
- The table bellow describes the information that will be reported and provide
- information how to interpret it.
+ for each backend that is currently running a <command>COPY</command> command.
+ The table below describes the information that will be reported and provides
+ information about how to interpret it.
</para>
<table id="pg-stat-progress-copy-view" xreflabel="pg_stat_progress_copy">
@@ -6445,7 +6445,7 @@ SELECT pg_stat_get_backend_pid(s.backendid) AS pid,
<row>
<entry role="catalog_table_entry"><para role="column_definition">
- <structfield>datid</structfield> <type>text</type>
+ <structfield>datid</structfield> <type>oid</type>
</para>
<para>
OID of the database to which this backend is connected.
@@ -6467,7 +6467,7 @@ SELECT pg_stat_get_backend_pid(s.backendid) AS pid,
</para>
<para>
OID of the table on which the <command>COPY</command> command is executed.
- It is set to 0 if <command>SELECT</command> query is provided.
+ It is set to 0 if copying from a <command>SELECT</command> query.
</para></entry>
</row>
--
2.17.0
--aM3YZ0Iwxop3KEKx
Content-Type: text/x-diff; charset=us-ascii
Content-Disposition: attachment;
filename="0001-doc-review-COPY-progress-8a4f618e7ae3cb11b0b37d0f06f.patch"
^ permalink raw reply [nested|flat] 54+ messages in thread
* [PATCH] doc review: COPY progress: 8a4f618e7ae3cb11b0b37d0f06f05c8ff905833f
@ 2021-01-07 01:08 Justin Pryzby <[email protected]>
0 siblings, 0 replies; 54+ messages in thread
From: Justin Pryzby @ 2021-01-07 01:08 UTC (permalink / raw)
---
doc/src/sgml/monitoring.sgml | 10 +++++-----
1 file changed, 5 insertions(+), 5 deletions(-)
diff --git a/doc/src/sgml/monitoring.sgml b/doc/src/sgml/monitoring.sgml
index 43fe8ae383..3cdb1aff3c 100644
--- a/doc/src/sgml/monitoring.sgml
+++ b/doc/src/sgml/monitoring.sgml
@@ -6414,9 +6414,9 @@ SELECT pg_stat_get_backend_pid(s.backendid) AS pid,
<para>
Whenever <command>COPY</command> is running, the
<structname>pg_stat_progress_copy</structname> view will contain one row
- for each backend that is currently running <command>COPY</command> command.
- The table bellow describes the information that will be reported and provide
- information how to interpret it.
+ for each backend that is currently running a <command>COPY</command> command.
+ The table below describes the information that will be reported and provides
+ information about how to interpret it.
</para>
<table id="pg-stat-progress-copy-view" xreflabel="pg_stat_progress_copy">
@@ -6445,7 +6445,7 @@ SELECT pg_stat_get_backend_pid(s.backendid) AS pid,
<row>
<entry role="catalog_table_entry"><para role="column_definition">
- <structfield>datid</structfield> <type>text</type>
+ <structfield>datid</structfield> <type>oid</type>
</para>
<para>
OID of the database to which this backend is connected.
@@ -6467,7 +6467,7 @@ SELECT pg_stat_get_backend_pid(s.backendid) AS pid,
</para>
<para>
OID of the table on which the <command>COPY</command> command is executed.
- It is set to 0 if <command>SELECT</command> query is provided.
+ It is set to 0 if copying from a <command>SELECT</command> query.
</para></entry>
</row>
--
2.17.0
--aM3YZ0Iwxop3KEKx--
^ permalink raw reply [nested|flat] 54+ messages in thread
* [PATCH] doc review: COPY progress: 8a4f618e7ae3cb11b0b37d0f06f05c8ff905833f
@ 2021-01-07 01:08 Justin Pryzby <[email protected]>
0 siblings, 0 replies; 54+ messages in thread
From: Justin Pryzby @ 2021-01-07 01:08 UTC (permalink / raw)
---
doc/src/sgml/monitoring.sgml | 10 +++++-----
1 file changed, 5 insertions(+), 5 deletions(-)
diff --git a/doc/src/sgml/monitoring.sgml b/doc/src/sgml/monitoring.sgml
index 43fe8ae383..3cdb1aff3c 100644
--- a/doc/src/sgml/monitoring.sgml
+++ b/doc/src/sgml/monitoring.sgml
@@ -6414,9 +6414,9 @@ SELECT pg_stat_get_backend_pid(s.backendid) AS pid,
<para>
Whenever <command>COPY</command> is running, the
<structname>pg_stat_progress_copy</structname> view will contain one row
- for each backend that is currently running <command>COPY</command> command.
- The table bellow describes the information that will be reported and provide
- information how to interpret it.
+ for each backend that is currently running a <command>COPY</command> command.
+ The table below describes the information that will be reported and provides
+ information about how to interpret it.
</para>
<table id="pg-stat-progress-copy-view" xreflabel="pg_stat_progress_copy">
@@ -6445,7 +6445,7 @@ SELECT pg_stat_get_backend_pid(s.backendid) AS pid,
<row>
<entry role="catalog_table_entry"><para role="column_definition">
- <structfield>datid</structfield> <type>text</type>
+ <structfield>datid</structfield> <type>oid</type>
</para>
<para>
OID of the database to which this backend is connected.
@@ -6467,7 +6467,7 @@ SELECT pg_stat_get_backend_pid(s.backendid) AS pid,
</para>
<para>
OID of the table on which the <command>COPY</command> command is executed.
- It is set to 0 if <command>SELECT</command> query is provided.
+ It is set to 0 if copying from a <command>SELECT</command> query.
</para></entry>
</row>
--
2.17.0
--aM3YZ0Iwxop3KEKx
Content-Type: text/x-diff; charset=us-ascii
Content-Disposition: attachment;
filename="0001-doc-review-COPY-progress-8a4f618e7ae3cb11b0b37d0f06f.patch"
^ permalink raw reply [nested|flat] 54+ messages in thread
* [PATCH] doc review: COPY progress: 8a4f618e7ae3cb11b0b37d0f06f05c8ff905833f
@ 2021-01-07 01:08 Justin Pryzby <[email protected]>
0 siblings, 0 replies; 54+ messages in thread
From: Justin Pryzby @ 2021-01-07 01:08 UTC (permalink / raw)
---
doc/src/sgml/monitoring.sgml | 10 +++++-----
1 file changed, 5 insertions(+), 5 deletions(-)
diff --git a/doc/src/sgml/monitoring.sgml b/doc/src/sgml/monitoring.sgml
index 43fe8ae383..3cdb1aff3c 100644
--- a/doc/src/sgml/monitoring.sgml
+++ b/doc/src/sgml/monitoring.sgml
@@ -6414,9 +6414,9 @@ SELECT pg_stat_get_backend_pid(s.backendid) AS pid,
<para>
Whenever <command>COPY</command> is running, the
<structname>pg_stat_progress_copy</structname> view will contain one row
- for each backend that is currently running <command>COPY</command> command.
- The table bellow describes the information that will be reported and provide
- information how to interpret it.
+ for each backend that is currently running a <command>COPY</command> command.
+ The table below describes the information that will be reported and provides
+ information about how to interpret it.
</para>
<table id="pg-stat-progress-copy-view" xreflabel="pg_stat_progress_copy">
@@ -6445,7 +6445,7 @@ SELECT pg_stat_get_backend_pid(s.backendid) AS pid,
<row>
<entry role="catalog_table_entry"><para role="column_definition">
- <structfield>datid</structfield> <type>text</type>
+ <structfield>datid</structfield> <type>oid</type>
</para>
<para>
OID of the database to which this backend is connected.
@@ -6467,7 +6467,7 @@ SELECT pg_stat_get_backend_pid(s.backendid) AS pid,
</para>
<para>
OID of the table on which the <command>COPY</command> command is executed.
- It is set to 0 if <command>SELECT</command> query is provided.
+ It is set to 0 if copying from a <command>SELECT</command> query.
</para></entry>
</row>
--
2.17.0
--aM3YZ0Iwxop3KEKx--
^ permalink raw reply [nested|flat] 54+ messages in thread
* [PATCH] doc review: COPY progress: 8a4f618e7ae3cb11b0b37d0f06f05c8ff905833f
@ 2021-01-07 01:08 Justin Pryzby <[email protected]>
0 siblings, 0 replies; 54+ messages in thread
From: Justin Pryzby @ 2021-01-07 01:08 UTC (permalink / raw)
---
doc/src/sgml/monitoring.sgml | 10 +++++-----
1 file changed, 5 insertions(+), 5 deletions(-)
diff --git a/doc/src/sgml/monitoring.sgml b/doc/src/sgml/monitoring.sgml
index 43fe8ae383..3cdb1aff3c 100644
--- a/doc/src/sgml/monitoring.sgml
+++ b/doc/src/sgml/monitoring.sgml
@@ -6414,9 +6414,9 @@ SELECT pg_stat_get_backend_pid(s.backendid) AS pid,
<para>
Whenever <command>COPY</command> is running, the
<structname>pg_stat_progress_copy</structname> view will contain one row
- for each backend that is currently running <command>COPY</command> command.
- The table bellow describes the information that will be reported and provide
- information how to interpret it.
+ for each backend that is currently running a <command>COPY</command> command.
+ The table below describes the information that will be reported and provides
+ information about how to interpret it.
</para>
<table id="pg-stat-progress-copy-view" xreflabel="pg_stat_progress_copy">
@@ -6445,7 +6445,7 @@ SELECT pg_stat_get_backend_pid(s.backendid) AS pid,
<row>
<entry role="catalog_table_entry"><para role="column_definition">
- <structfield>datid</structfield> <type>text</type>
+ <structfield>datid</structfield> <type>oid</type>
</para>
<para>
OID of the database to which this backend is connected.
@@ -6467,7 +6467,7 @@ SELECT pg_stat_get_backend_pid(s.backendid) AS pid,
</para>
<para>
OID of the table on which the <command>COPY</command> command is executed.
- It is set to 0 if <command>SELECT</command> query is provided.
+ It is set to 0 if copying from a <command>SELECT</command> query.
</para></entry>
</row>
--
2.17.0
--aM3YZ0Iwxop3KEKx
Content-Type: text/x-diff; charset=us-ascii
Content-Disposition: attachment;
filename="0001-doc-review-COPY-progress-8a4f618e7ae3cb11b0b37d0f06f.patch"
^ permalink raw reply [nested|flat] 54+ messages in thread
* [PATCH] doc review: COPY progress: 8a4f618e7ae3cb11b0b37d0f06f05c8ff905833f
@ 2021-01-07 01:08 Justin Pryzby <[email protected]>
0 siblings, 0 replies; 54+ messages in thread
From: Justin Pryzby @ 2021-01-07 01:08 UTC (permalink / raw)
---
doc/src/sgml/monitoring.sgml | 10 +++++-----
1 file changed, 5 insertions(+), 5 deletions(-)
diff --git a/doc/src/sgml/monitoring.sgml b/doc/src/sgml/monitoring.sgml
index 43fe8ae383..3cdb1aff3c 100644
--- a/doc/src/sgml/monitoring.sgml
+++ b/doc/src/sgml/monitoring.sgml
@@ -6414,9 +6414,9 @@ SELECT pg_stat_get_backend_pid(s.backendid) AS pid,
<para>
Whenever <command>COPY</command> is running, the
<structname>pg_stat_progress_copy</structname> view will contain one row
- for each backend that is currently running <command>COPY</command> command.
- The table bellow describes the information that will be reported and provide
- information how to interpret it.
+ for each backend that is currently running a <command>COPY</command> command.
+ The table below describes the information that will be reported and provides
+ information about how to interpret it.
</para>
<table id="pg-stat-progress-copy-view" xreflabel="pg_stat_progress_copy">
@@ -6445,7 +6445,7 @@ SELECT pg_stat_get_backend_pid(s.backendid) AS pid,
<row>
<entry role="catalog_table_entry"><para role="column_definition">
- <structfield>datid</structfield> <type>text</type>
+ <structfield>datid</structfield> <type>oid</type>
</para>
<para>
OID of the database to which this backend is connected.
@@ -6467,7 +6467,7 @@ SELECT pg_stat_get_backend_pid(s.backendid) AS pid,
</para>
<para>
OID of the table on which the <command>COPY</command> command is executed.
- It is set to 0 if <command>SELECT</command> query is provided.
+ It is set to 0 if copying from a <command>SELECT</command> query.
</para></entry>
</row>
--
2.17.0
--aM3YZ0Iwxop3KEKx--
^ permalink raw reply [nested|flat] 54+ messages in thread
* [PATCH] doc review: COPY progress: 8a4f618e7ae3cb11b0b37d0f06f05c8ff905833f
@ 2021-01-07 01:08 Justin Pryzby <[email protected]>
0 siblings, 0 replies; 54+ messages in thread
From: Justin Pryzby @ 2021-01-07 01:08 UTC (permalink / raw)
---
doc/src/sgml/monitoring.sgml | 10 +++++-----
1 file changed, 5 insertions(+), 5 deletions(-)
diff --git a/doc/src/sgml/monitoring.sgml b/doc/src/sgml/monitoring.sgml
index 43fe8ae383..3cdb1aff3c 100644
--- a/doc/src/sgml/monitoring.sgml
+++ b/doc/src/sgml/monitoring.sgml
@@ -6414,9 +6414,9 @@ SELECT pg_stat_get_backend_pid(s.backendid) AS pid,
<para>
Whenever <command>COPY</command> is running, the
<structname>pg_stat_progress_copy</structname> view will contain one row
- for each backend that is currently running <command>COPY</command> command.
- The table bellow describes the information that will be reported and provide
- information how to interpret it.
+ for each backend that is currently running a <command>COPY</command> command.
+ The table below describes the information that will be reported and provides
+ information about how to interpret it.
</para>
<table id="pg-stat-progress-copy-view" xreflabel="pg_stat_progress_copy">
@@ -6445,7 +6445,7 @@ SELECT pg_stat_get_backend_pid(s.backendid) AS pid,
<row>
<entry role="catalog_table_entry"><para role="column_definition">
- <structfield>datid</structfield> <type>text</type>
+ <structfield>datid</structfield> <type>oid</type>
</para>
<para>
OID of the database to which this backend is connected.
@@ -6467,7 +6467,7 @@ SELECT pg_stat_get_backend_pid(s.backendid) AS pid,
</para>
<para>
OID of the table on which the <command>COPY</command> command is executed.
- It is set to 0 if <command>SELECT</command> query is provided.
+ It is set to 0 if copying from a <command>SELECT</command> query.
</para></entry>
</row>
--
2.17.0
--aM3YZ0Iwxop3KEKx
Content-Type: text/x-diff; charset=us-ascii
Content-Disposition: attachment;
filename="0001-doc-review-COPY-progress-8a4f618e7ae3cb11b0b37d0f06f.patch"
^ permalink raw reply [nested|flat] 54+ messages in thread
* [PATCH] doc review: COPY progress: 8a4f618e7ae3cb11b0b37d0f06f05c8ff905833f
@ 2021-01-07 01:08 Justin Pryzby <[email protected]>
0 siblings, 0 replies; 54+ messages in thread
From: Justin Pryzby @ 2021-01-07 01:08 UTC (permalink / raw)
---
doc/src/sgml/monitoring.sgml | 10 +++++-----
1 file changed, 5 insertions(+), 5 deletions(-)
diff --git a/doc/src/sgml/monitoring.sgml b/doc/src/sgml/monitoring.sgml
index 43fe8ae383..3cdb1aff3c 100644
--- a/doc/src/sgml/monitoring.sgml
+++ b/doc/src/sgml/monitoring.sgml
@@ -6414,9 +6414,9 @@ SELECT pg_stat_get_backend_pid(s.backendid) AS pid,
<para>
Whenever <command>COPY</command> is running, the
<structname>pg_stat_progress_copy</structname> view will contain one row
- for each backend that is currently running <command>COPY</command> command.
- The table bellow describes the information that will be reported and provide
- information how to interpret it.
+ for each backend that is currently running a <command>COPY</command> command.
+ The table below describes the information that will be reported and provides
+ information about how to interpret it.
</para>
<table id="pg-stat-progress-copy-view" xreflabel="pg_stat_progress_copy">
@@ -6445,7 +6445,7 @@ SELECT pg_stat_get_backend_pid(s.backendid) AS pid,
<row>
<entry role="catalog_table_entry"><para role="column_definition">
- <structfield>datid</structfield> <type>text</type>
+ <structfield>datid</structfield> <type>oid</type>
</para>
<para>
OID of the database to which this backend is connected.
@@ -6467,7 +6467,7 @@ SELECT pg_stat_get_backend_pid(s.backendid) AS pid,
</para>
<para>
OID of the table on which the <command>COPY</command> command is executed.
- It is set to 0 if <command>SELECT</command> query is provided.
+ It is set to 0 if copying from a <command>SELECT</command> query.
</para></entry>
</row>
--
2.17.0
--aM3YZ0Iwxop3KEKx--
^ permalink raw reply [nested|flat] 54+ messages in thread
* [PATCH] doc review: COPY progress: 8a4f618e7ae3cb11b0b37d0f06f05c8ff905833f
@ 2021-01-07 01:08 Justin Pryzby <[email protected]>
0 siblings, 0 replies; 54+ messages in thread
From: Justin Pryzby @ 2021-01-07 01:08 UTC (permalink / raw)
---
doc/src/sgml/monitoring.sgml | 10 +++++-----
1 file changed, 5 insertions(+), 5 deletions(-)
diff --git a/doc/src/sgml/monitoring.sgml b/doc/src/sgml/monitoring.sgml
index 43fe8ae383..3cdb1aff3c 100644
--- a/doc/src/sgml/monitoring.sgml
+++ b/doc/src/sgml/monitoring.sgml
@@ -6414,9 +6414,9 @@ SELECT pg_stat_get_backend_pid(s.backendid) AS pid,
<para>
Whenever <command>COPY</command> is running, the
<structname>pg_stat_progress_copy</structname> view will contain one row
- for each backend that is currently running <command>COPY</command> command.
- The table bellow describes the information that will be reported and provide
- information how to interpret it.
+ for each backend that is currently running a <command>COPY</command> command.
+ The table below describes the information that will be reported and provides
+ information about how to interpret it.
</para>
<table id="pg-stat-progress-copy-view" xreflabel="pg_stat_progress_copy">
@@ -6445,7 +6445,7 @@ SELECT pg_stat_get_backend_pid(s.backendid) AS pid,
<row>
<entry role="catalog_table_entry"><para role="column_definition">
- <structfield>datid</structfield> <type>text</type>
+ <structfield>datid</structfield> <type>oid</type>
</para>
<para>
OID of the database to which this backend is connected.
@@ -6467,7 +6467,7 @@ SELECT pg_stat_get_backend_pid(s.backendid) AS pid,
</para>
<para>
OID of the table on which the <command>COPY</command> command is executed.
- It is set to 0 if <command>SELECT</command> query is provided.
+ It is set to 0 if copying from a <command>SELECT</command> query.
</para></entry>
</row>
--
2.17.0
--aM3YZ0Iwxop3KEKx
Content-Type: text/x-diff; charset=us-ascii
Content-Disposition: attachment;
filename="0001-doc-review-COPY-progress-8a4f618e7ae3cb11b0b37d0f06f.patch"
^ permalink raw reply [nested|flat] 54+ messages in thread
* [PATCH] doc review: COPY progress: 8a4f618e7ae3cb11b0b37d0f06f05c8ff905833f
@ 2021-01-07 01:08 Justin Pryzby <[email protected]>
0 siblings, 0 replies; 54+ messages in thread
From: Justin Pryzby @ 2021-01-07 01:08 UTC (permalink / raw)
---
doc/src/sgml/monitoring.sgml | 10 +++++-----
1 file changed, 5 insertions(+), 5 deletions(-)
diff --git a/doc/src/sgml/monitoring.sgml b/doc/src/sgml/monitoring.sgml
index 43fe8ae383..3cdb1aff3c 100644
--- a/doc/src/sgml/monitoring.sgml
+++ b/doc/src/sgml/monitoring.sgml
@@ -6414,9 +6414,9 @@ SELECT pg_stat_get_backend_pid(s.backendid) AS pid,
<para>
Whenever <command>COPY</command> is running, the
<structname>pg_stat_progress_copy</structname> view will contain one row
- for each backend that is currently running <command>COPY</command> command.
- The table bellow describes the information that will be reported and provide
- information how to interpret it.
+ for each backend that is currently running a <command>COPY</command> command.
+ The table below describes the information that will be reported and provides
+ information about how to interpret it.
</para>
<table id="pg-stat-progress-copy-view" xreflabel="pg_stat_progress_copy">
@@ -6445,7 +6445,7 @@ SELECT pg_stat_get_backend_pid(s.backendid) AS pid,
<row>
<entry role="catalog_table_entry"><para role="column_definition">
- <structfield>datid</structfield> <type>text</type>
+ <structfield>datid</structfield> <type>oid</type>
</para>
<para>
OID of the database to which this backend is connected.
@@ -6467,7 +6467,7 @@ SELECT pg_stat_get_backend_pid(s.backendid) AS pid,
</para>
<para>
OID of the table on which the <command>COPY</command> command is executed.
- It is set to 0 if <command>SELECT</command> query is provided.
+ It is set to 0 if copying from a <command>SELECT</command> query.
</para></entry>
</row>
--
2.17.0
--aM3YZ0Iwxop3KEKx--
^ permalink raw reply [nested|flat] 54+ messages in thread
* [PATCH] doc review: COPY progress: 8a4f618e7ae3cb11b0b37d0f06f05c8ff905833f
@ 2021-01-07 01:08 Justin Pryzby <[email protected]>
0 siblings, 0 replies; 54+ messages in thread
From: Justin Pryzby @ 2021-01-07 01:08 UTC (permalink / raw)
---
doc/src/sgml/monitoring.sgml | 10 +++++-----
1 file changed, 5 insertions(+), 5 deletions(-)
diff --git a/doc/src/sgml/monitoring.sgml b/doc/src/sgml/monitoring.sgml
index 43fe8ae383..3cdb1aff3c 100644
--- a/doc/src/sgml/monitoring.sgml
+++ b/doc/src/sgml/monitoring.sgml
@@ -6414,9 +6414,9 @@ SELECT pg_stat_get_backend_pid(s.backendid) AS pid,
<para>
Whenever <command>COPY</command> is running, the
<structname>pg_stat_progress_copy</structname> view will contain one row
- for each backend that is currently running <command>COPY</command> command.
- The table bellow describes the information that will be reported and provide
- information how to interpret it.
+ for each backend that is currently running a <command>COPY</command> command.
+ The table below describes the information that will be reported and provides
+ information about how to interpret it.
</para>
<table id="pg-stat-progress-copy-view" xreflabel="pg_stat_progress_copy">
@@ -6445,7 +6445,7 @@ SELECT pg_stat_get_backend_pid(s.backendid) AS pid,
<row>
<entry role="catalog_table_entry"><para role="column_definition">
- <structfield>datid</structfield> <type>text</type>
+ <structfield>datid</structfield> <type>oid</type>
</para>
<para>
OID of the database to which this backend is connected.
@@ -6467,7 +6467,7 @@ SELECT pg_stat_get_backend_pid(s.backendid) AS pid,
</para>
<para>
OID of the table on which the <command>COPY</command> command is executed.
- It is set to 0 if <command>SELECT</command> query is provided.
+ It is set to 0 if copying from a <command>SELECT</command> query.
</para></entry>
</row>
--
2.17.0
--aM3YZ0Iwxop3KEKx
Content-Type: text/x-diff; charset=us-ascii
Content-Disposition: attachment;
filename="0001-doc-review-COPY-progress-8a4f618e7ae3cb11b0b37d0f06f.patch"
^ permalink raw reply [nested|flat] 54+ messages in thread
* [PATCH] doc review: COPY progress: 8a4f618e7ae3cb11b0b37d0f06f05c8ff905833f
@ 2021-01-07 01:08 Justin Pryzby <[email protected]>
0 siblings, 0 replies; 54+ messages in thread
From: Justin Pryzby @ 2021-01-07 01:08 UTC (permalink / raw)
---
doc/src/sgml/monitoring.sgml | 10 +++++-----
1 file changed, 5 insertions(+), 5 deletions(-)
diff --git a/doc/src/sgml/monitoring.sgml b/doc/src/sgml/monitoring.sgml
index 43fe8ae383..3cdb1aff3c 100644
--- a/doc/src/sgml/monitoring.sgml
+++ b/doc/src/sgml/monitoring.sgml
@@ -6414,9 +6414,9 @@ SELECT pg_stat_get_backend_pid(s.backendid) AS pid,
<para>
Whenever <command>COPY</command> is running, the
<structname>pg_stat_progress_copy</structname> view will contain one row
- for each backend that is currently running <command>COPY</command> command.
- The table bellow describes the information that will be reported and provide
- information how to interpret it.
+ for each backend that is currently running a <command>COPY</command> command.
+ The table below describes the information that will be reported and provides
+ information about how to interpret it.
</para>
<table id="pg-stat-progress-copy-view" xreflabel="pg_stat_progress_copy">
@@ -6445,7 +6445,7 @@ SELECT pg_stat_get_backend_pid(s.backendid) AS pid,
<row>
<entry role="catalog_table_entry"><para role="column_definition">
- <structfield>datid</structfield> <type>text</type>
+ <structfield>datid</structfield> <type>oid</type>
</para>
<para>
OID of the database to which this backend is connected.
@@ -6467,7 +6467,7 @@ SELECT pg_stat_get_backend_pid(s.backendid) AS pid,
</para>
<para>
OID of the table on which the <command>COPY</command> command is executed.
- It is set to 0 if <command>SELECT</command> query is provided.
+ It is set to 0 if copying from a <command>SELECT</command> query.
</para></entry>
</row>
--
2.17.0
--aM3YZ0Iwxop3KEKx--
^ permalink raw reply [nested|flat] 54+ messages in thread
* BUG #17540: Prepared statement: PG switches to a generic query plan which is consistently much slower
@ 2022-07-05 22:13 PG Bug reporting form <[email protected]>
0 siblings, 2 replies; 54+ messages in thread
From: PG Bug reporting form @ 2022-07-05 22:13 UTC (permalink / raw)
To: [email protected]; +Cc: [email protected]
The following bug has been logged on the website:
Bug reference: 17540
Logged by: William Duclot
Email address: [email protected]
PostgreSQL version: 14.4
Operating system: GNU/Linux (Red Hat 8.5.0)
Description:
My application uses prepared statements. This section of the documentation
is going to be very relevant to the rest of this report:
https://www.postgresql.org/docs/current/sql-prepare.html#SQL-PREPARE-NOTES.
This is a minimal reproduction of the problem I observe, which I will
explain below:
https://dbfiddle.uk/?rdbms=postgres_14&fiddle=6b01d161da27379844e7602a16543626
Scenario:
- I create a fairly simple table (id + timestamp). Timestamp is indexed.
- I create a simple-ish prepared statement for `SELECT MIN(id), MAX(id) from
relation_tuple_transaction WHERE timestamp >= $1;`
- I execute the prepared statement multiple times (> 5 times)
From the 6th time onwards, the query plan used by Postgres changes, which
isn't fully unexpected as the documentation linked above does make it clear
that Postgres might decide to change the query plan for a generic query plan
after the 5th execution. And indeed, the estimated "cost" of the generic
plan is lower than the custom plan's: therefore the query planner behaves
correctly according to the documentation.
Now, the problem: the execution of the generic plan is multiple orders of
magnitude slower than the custom query plan ("actual time" for the generic
plan is over 6500x slower), yet Postgres decides to stick with the generic
plan. Very unexpected for me: I was very happy with the first 5 plans, yet
Postgres decides to change the plan for another that's enormously slower and
stick with it.
Giving a different parameter passed to the prepared statement (eg `now() -
interval '5 days'`) does give a "slow" custom plan (similar to the generic
plan). This means that the query planner does not realise that the actual
parameter value matters a lot, and that the parameters used _in practice_
result in a faster plan than the generic plan (100% of the first 5
executions), and that therefore it shouldn't stick to the generic plan.
It is particularly insidious as actually I wasn't even aware I was using
prepared statements. Like most applications I use a database driver (pgx, in
Go) which I learnt uses `PQexecPrepared` under the hood, which creates a
sort of "unnamed prepared statement" behaving the same as this minimal
reproduction without me ever being aware that prepared statements are
involved anywhere between my code and the database. This makes debugging
very complex as there's no reason to suspect anything
prepared-statement-related and a manual EXPLAIN ANALYZE outside of a
prepared statement won't show the problem.
Note: setting `plan_cache_mode = force_custom_plan` database-wide solved the
immediate problem but is a workaround. It was a very welcome workaround,
though.
^ permalink raw reply [nested|flat] 54+ messages in thread
* Re: BUG #17540: Prepared statement: PG switches to a generic query plan which is consistently much slower
@ 2022-07-06 22:07 David G. Johnston <[email protected]>
parent: PG Bug reporting form <[email protected]>
1 sibling, 1 reply; 54+ messages in thread
From: David G. Johnston @ 2022-07-06 22:07 UTC (permalink / raw)
To: [email protected]; PostgreSQL mailing lists <[email protected]>
On Wed, Jul 6, 2022 at 2:41 PM PG Bug reporting form <[email protected]>
wrote:
> The following bug has been logged on the website:
>
> Bug reference: 17540
> Logged by: William Duclot
> Email address: [email protected]
> PostgreSQL version: 14.4
> Operating system: GNU/Linux (Red Hat 8.5.0)
> Description:
>
> This means that the query planner does not realise that the actual
> parameter value matters a lot, and that the parameters used _in practice_
> result in a faster plan than the generic plan (100% of the first 5
> executions), and that therefore it shouldn't stick to the generic plan.
>
I mean, it is the planner and so, no, it doesn't understand that the
executor encountered an issue.
> It is particularly insidious as actually I wasn't even aware I was using
> prepared statements. Like most applications I use a database driver (pgx,
> in
> Go) which I learnt uses `PQexecPrepared` under the hood, which creates a
> sort of "unnamed prepared statement" behaving the same as this minimal
> reproduction without me ever being aware that prepared statements are
> involved anywhere between my code and the database.
Yep, and the core project pretty much says that if you don't like this you
need to complain to the driver writer and ask them to provide you an
interface to the unnamed parse-bind-execute API which lets you perform
parameterization without memory, just safety.
PostgreSQL has built the needed tools to make this less problematic, and
has made solid attempts to improve matters in the current state of things.
There doesn't seem to be a bug here. There is potentially room for
improvement but no one presently is working on things in this area.
David J.
^ permalink raw reply [nested|flat] 54+ messages in thread
* Re: BUG #17540: Prepared statement: PG switches to a generic query plan which is consistently much slower
@ 2022-07-07 00:23 David Rowley <[email protected]>
parent: PG Bug reporting form <[email protected]>
1 sibling, 2 replies; 54+ messages in thread
From: David Rowley @ 2022-07-07 00:23 UTC (permalink / raw)
To: [email protected]; PostgreSQL mailing lists <[email protected]>
(On Thu, 7 Jul 2022 at 09:41, PG Bug reporting form
<[email protected]> wrote:
> Scenario:
> - I create a fairly simple table (id + timestamp). Timestamp is indexed.
> - I create a simple-ish prepared statement for `SELECT MIN(id), MAX(id) from
> relation_tuple_transaction WHERE timestamp >= $1;`
> - I execute the prepared statement multiple times (> 5 times)
>
> From the 6th time onwards, the query plan used by Postgres changes, which
> isn't fully unexpected as the documentation linked above does make it clear
> that Postgres might decide to change the query plan for a generic query plan
> after the 5th execution. And indeed, the estimated "cost" of the generic
> plan is lower than the custom plan's: therefore the query planner behaves
> correctly according to the documentation.
It's a pretty narrow fix for a fairly generic problem, but I think the
planner wouldn't have picked the pk_rttx index if build_minmax_path()
hadn't added the "id IS NOT NULL" qual.
I know that Andy Fan has been proposing a patch to add a Bitmapset
field to RelOptInfo to record the non-NULLable columns. That's a
fairly lightweight patch, so it might be worth adding that just so
build_minmax_path() can skip adding the NULL test if the column is a
NOT NULL column.
I see that preprocess_minmax_aggregates() won't touch anything that's
not a query to a single relation, so the Var can't be NULLable from
being on the outside of an outer join. So it looks like to plumb in
Andy's patch, build_minmax_path() would need to be modified to check
if mminfo->target is a plain Var and then test if that Var is NOT
NULLable then skip adding the NullTest.
All seems fairly trivial. It's just a fairly narrow fix to side-step a
more generic costing problem we have for Params. I just don't have
any bright ideas on how to fix the more generic problem right now.
I've been looking for a good excuse to commit Andy's NOT NULL patch so
that he has some more foundations for the other work he's doing. This
might be that excuse.
Does anyone think differently?
David
[1] https://www.postgresql.org/message-id/[email protected]...
^ permalink raw reply [nested|flat] 54+ messages in thread
* Re: BUG #17540: Prepared statement: PG switches to a generic query plan which is consistently much slower
@ 2022-07-07 00:46 David Rowley <[email protected]>
parent: David Rowley <[email protected]>
1 sibling, 0 replies; 54+ messages in thread
From: David Rowley @ 2022-07-07 00:46 UTC (permalink / raw)
To: [email protected]; PostgreSQL mailing lists <[email protected]>
On Thu, 7 Jul 2022 at 12:23, David Rowley <[email protected]> wrote:
> [1] https://www.postgresql.org/message-id/[email protected]...
Correction: [1]
https://www.postgresql.org/message-id/CAKU4AWpUA8dyVSU1nfCJz71mu6VEjbGS1uy8azrt5CdyoZqGQA%40mail.gma...
David
^ permalink raw reply [nested|flat] 54+ messages in thread
* Re: BUG #17540: Prepared statement: PG switches to a generic query plan which is consistently much slower
@ 2022-07-07 00:46 Andres Freund <[email protected]>
parent: David G. Johnston <[email protected]>
0 siblings, 2 replies; 54+ messages in thread
From: Andres Freund @ 2022-07-07 00:46 UTC (permalink / raw)
To: David G. Johnston <[email protected]>; +Cc: [email protected]; PostgreSQL mailing lists <[email protected]>
Hi,
On 2022-07-06 15:07:46 -0700, David G. Johnston wrote:
> On Wed, Jul 6, 2022 at 2:41 PM PG Bug reporting form <[email protected]>
> wrote:
> > It is particularly insidious as actually I wasn't even aware I was using
> > prepared statements. Like most applications I use a database driver (pgx,
> > in
> > Go) which I learnt uses `PQexecPrepared` under the hood, which creates a
> > sort of "unnamed prepared statement" behaving the same as this minimal
> > reproduction without me ever being aware that prepared statements are
> > involved anywhere between my code and the database.
>
>
> Yep, and the core project pretty much says that if you don't like this you
> need to complain to the driver writer and ask them to provide you an
> interface to the unnamed parse-bind-execute API which lets you perform
> parameterization without memory, just safety.
>
> PostgreSQL has built the needed tools to make this less problematic, and
> has made solid attempts to improve matters in the current state of things.
> There doesn't seem to be a bug here. There is potentially room for
> improvement but no one presently is working on things in this area.
I think the cost for the slow plan being so much cheaper can almost be
qualified as bug.
The slow plan seems pretty nonsensical to me. ISTM that something in the
costing there is at least almost broken.
Result (cost=1.06..1.07 rows=1 width=16) (actual time=148.732..148.734 rows=1 loops=1)
Buffers: shared hit=4935
InitPlan 1 (returns $0)
-> Limit (cost=0.42..0.53 rows=1 width=8) (actual time=73.859..73.860 rows=0 loops=1)
Buffers: shared hit=2113
-> Index Scan using pk_rttx on relation_tuple_transaction (cost=0.42..9445.44 rows=86400 width=8) (actual time=73.857..73.858 rows=0 loops=1)
Index Cond: (id IS NOT NULL)
Filter: ("timestamp" >= $1)
Rows Removed by Filter: 259201
Buffers: shared hit=2113
InitPlan 2 (returns $1)
-> Limit (cost=0.42..0.53 rows=1 width=8) (actual time=74.869..74.870 rows=0 loops=1)
Buffers: shared hit=2822
-> Index Scan Backward using pk_rttx on relation_tuple_transaction relation_tuple_transaction_1 (cost=0.42..9445.44 rows=86400 width=8) (actual time=74.868..74.868 rows=0 loops=1)
Index Cond: (id IS NOT NULL)
Filter: ("timestamp" >= $1)
Rows Removed by Filter: 259201
Buffers: shared hit=2822
Planning Time: 0.224 ms
Execution Time: 148.781 ms
The planner assumes the table has 259201 rows. Somehow we end up
assuming that a estimate-less filter reduces the number of rows to 86400
both on a backward and a forward scan.
And for some reason we don't take the filter clause into account *at
all* for the cost of returning the first row.
SET enable_seqscan = false;
EXPLAIN SELECT * FROM relation_tuple_transaction WHERE id IS NOT NULL LIMIT 1;
┌─────────────────────────────────────────────────────────────────────────────────────────────────────────┐
│ QUERY PLAN │
├─────────────────────────────────────────────────────────────────────────────────────────────────────────┤
│ Limit (cost=0.42..0.45 rows=1 width=16) │
│ -> Index Scan using pk_rttx on relation_tuple_transaction (cost=0.42..8797.44 rows=259201 width=16) │
│ Index Cond: (id IS NOT NULL) │
└─────────────────────────────────────────────────────────────────────────────────────────────────────────┘
(3 rows)
It's also pointless that we use "Index Cond: (id IS NOT NULL)" for a
primary key index, but that's a minor thing.
Greetings,
Andres Freund
^ permalink raw reply [nested|flat] 54+ messages in thread
* Re: BUG #17540: Prepared statement: PG switches to a generic query plan which is consistently much slower
@ 2022-07-07 01:54 David Rowley <[email protected]>
parent: Andres Freund <[email protected]>
1 sibling, 0 replies; 54+ messages in thread
From: David Rowley @ 2022-07-07 01:54 UTC (permalink / raw)
To: Andres Freund <[email protected]>; +Cc: David G. Johnston <[email protected]>; [email protected]; PostgreSQL mailing lists <[email protected]>
On Thu, 7 Jul 2022 at 12:46, Andres Freund <[email protected]> wrote:
> I think the cost for the slow plan being so much cheaper can almost be
> qualified as bug.
>
> The slow plan seems pretty nonsensical to me. ISTM that something in the
> costing there is at least almost broken.
I forgot to mention what the "generic problem" is when I posted my
reply. I should have mentioned that this is how we cost LIMIT. We
assume that we'll find the LIMIT 1 row after incurring the scan cost
multiplied by (1 / 259201).
For the plan with WHERE timestamp >= $1, the seqscan plan looks pretty
cheap for fetching DEFAULT_INEQ_SEL of the 259201 rows considering the
LIMIT multiples the cost of the scan by (1 / 86400).
David
^ permalink raw reply [nested|flat] 54+ messages in thread
* Re: BUG #17540: Prepared statement: PG switches to a generic query plan which is consistently much slower
@ 2022-07-07 03:06 Tom Lane <[email protected]>
parent: David Rowley <[email protected]>
1 sibling, 1 reply; 54+ messages in thread
From: Tom Lane @ 2022-07-07 03:06 UTC (permalink / raw)
To: David Rowley <[email protected]>; +Cc: [email protected]; PostgreSQL mailing lists <[email protected]>
David Rowley <[email protected]> writes:
> I've been looking for a good excuse to commit Andy's NOT NULL patch so
> that he has some more foundations for the other work he's doing. This
> might be that excuse.
> Does anyone think differently?
While I don't have any problem with tracking column NOT NULL flags
in RelOptInfo once the planner has a use for that info, I'm not sure
that we have a solid use-case for it quite yet. In particular, the
fact that the table column is marked NOT NULL doesn't mean that any
particular occurrence of that column's Var can be freely assumed to be
non-null. The patch I'm working on to label Vars that have possibly
been nulled by outer joins [1] seems like essential infrastructure for
doing anything very useful with the info.
Maybe that objection doesn't apply to build_minmax_path's usage in
particular, but that's an awfully narrow use-case.
regards, tom lane
[1] https://www.postgresql.org/message-id/flat/[email protected]
^ permalink raw reply [nested|flat] 54+ messages in thread
* Re: BUG #17540: Prepared statement: PG switches to a generic query plan which is consistently much slower
@ 2022-07-07 03:13 Tom Lane <[email protected]>
parent: Andres Freund <[email protected]>
1 sibling, 1 reply; 54+ messages in thread
From: Tom Lane @ 2022-07-07 03:13 UTC (permalink / raw)
To: Andres Freund <[email protected]>; +Cc: David G. Johnston <[email protected]>; [email protected]; PostgreSQL mailing lists <[email protected]>
Andres Freund <[email protected]> writes:
> I think the cost for the slow plan being so much cheaper can almost be
> qualified as bug.
> The slow plan seems pretty nonsensical to me. ISTM that something in the
> costing there is at least almost broken.
I think this is probably an instance of the known problem that a generic
plan is made without knowledge of the actual parameter values, and that
can lead us to make statistical assumptions that are not valid for the
actual values, but nonetheless make one plan look cheaper than another
even though the opposite is true given the actual values. In essence,
comparing the cost estimate for the generic plan to the cost estimate
for a custom plan is not really logically valid, because those estimates
are founded on different statistics. I don't know how to fix that :-(.
regards, tom lane
^ permalink raw reply [nested|flat] 54+ messages in thread
* Re: BUG #17540: Prepared statement: PG switches to a generic query plan which is consistently much slower
@ 2022-07-07 03:31 David Rowley <[email protected]>
parent: Tom Lane <[email protected]>
0 siblings, 1 reply; 54+ messages in thread
From: David Rowley @ 2022-07-07 03:31 UTC (permalink / raw)
To: Tom Lane <[email protected]>; +Cc: [email protected]; PostgreSQL mailing lists <[email protected]>
On Thu, 7 Jul 2022 at 15:07, Tom Lane <[email protected]> wrote:
> While I don't have any problem with tracking column NOT NULL flags
> in RelOptInfo once the planner has a use for that info, I'm not sure
> that we have a solid use-case for it quite yet. In particular, the
> fact that the table column is marked NOT NULL doesn't mean that any
> particular occurrence of that column's Var can be freely assumed to be
> non-null. The patch I'm working on to label Vars that have possibly
> been nulled by outer joins [1] seems like essential infrastructure for
> doing anything very useful with the info.
I was aware that you'd done that work. I'm interested in it, but just
not found the time to look yet.
> Maybe that objection doesn't apply to build_minmax_path's usage in
> particular, but that's an awfully narrow use-case.
I thought I'd quickly put the idea together and fairly quickly noticed
that we do preprocess_minmax_aggregates() in grouping_planner(), which
is long before we load the RelOptInfo data in
add_base_rels_to_query(), which is called in query_planner(). I
considered if we could move the preprocess_minmax_aggregates(), but
that does not seem right, although, surprisingly, no tests seem to
fail from doing so. I'd have expected at least some EXPLAIN outputs to
have changed from the no-longer-present IS NOT NULL quals.
I imagine a much less narrow case would be to check for redundant
RestrictInfos in distribute_restrictinfo_to_rels(). That would also
catch cases such as WHERE non_nullable_col IS NULL, provided that qual
made it down to baserestrictinfo. When I realised that, I thought I
might be starting to overlap with your work in the link below.
> [1] https://www.postgresql.org/message-id/flat/[email protected]
The 2 attached patches do fix the bad reported plan, it's just that
it's a very roundabout way of fixing it
Anyway, I've no current plans to take the attached any further. I
think it'll be better to pursue your NULLable-Var stuff and see if we
can do something more generic like remove provably redundant NullTests
from baserestrictinfo.
David
From 0372cba1ea87d6eb10e21133461c1db525dbcf06 Mon Sep 17 00:00:00 2001
From: David Rowley <[email protected]>
Date: Thu, 7 Jul 2022 13:02:29 +1200
Subject: [PATCH v1 1/2] Track NOT NULL columns in RelOptInfo for base
relations
Author: Andy Fan
Discussion: https://postgr.es/m/CAKU4AWpUA8dyVSU1nfCJz71mu6VEjbGS1uy8azrt5CdyoZqGQA%40mail.gmail.com
---
src/backend/optimizer/util/plancat.c | 10 ++++++++++
src/backend/optimizer/util/relnode.c | 2 ++
src/include/nodes/pathnodes.h | 2 ++
3 files changed, 14 insertions(+)
diff --git a/src/backend/optimizer/util/plancat.c b/src/backend/optimizer/util/plancat.c
index 5012bfe142..7111284221 100644
--- a/src/backend/optimizer/util/plancat.c
+++ b/src/backend/optimizer/util/plancat.c
@@ -472,6 +472,16 @@ get_relation_info(PlannerInfo *root, Oid relationObjectId, bool inhparent,
if (inhparent && relation->rd_rel->relkind == RELKIND_PARTITIONED_TABLE)
set_relation_partition_info(root, rel, relation);
+ Assert(rel->notnullattrs == NULL);
+ for(int i = 0; i < relation->rd_att->natts; i++)
+ {
+ FormData_pg_attribute *attr = &relation->rd_att->attrs[i];
+
+ if (attr->attnotnull && !attr->attisdropped)
+ rel->notnullattrs = bms_add_member(rel->notnullattrs,
+ attr->attnum - FirstLowInvalidHeapAttributeNumber);
+ }
+
table_close(relation, NoLock);
/*
diff --git a/src/backend/optimizer/util/relnode.c b/src/backend/optimizer/util/relnode.c
index 520409f4ba..f7be6548ef 100644
--- a/src/backend/optimizer/util/relnode.c
+++ b/src/backend/optimizer/util/relnode.c
@@ -227,6 +227,7 @@ build_simple_rel(PlannerInfo *root, int relid, RelOptInfo *parent)
rel->lateral_vars = NIL;
rel->indexlist = NIL;
rel->statlist = NIL;
+ rel->notnullattrs = NULL;
rel->pages = 0;
rel->tuples = 0;
rel->allvisfrac = 0;
@@ -641,6 +642,7 @@ build_join_rel(PlannerInfo *root,
joinrel->lateral_referencers = NULL;
joinrel->indexlist = NIL;
joinrel->statlist = NIL;
+ joinrel->notnullattrs = NULL;
joinrel->pages = 0;
joinrel->tuples = 0;
joinrel->allvisfrac = 0;
diff --git a/src/include/nodes/pathnodes.h b/src/include/nodes/pathnodes.h
index b88cfb8dc0..5f81ecc3b5 100644
--- a/src/include/nodes/pathnodes.h
+++ b/src/include/nodes/pathnodes.h
@@ -758,6 +758,8 @@ typedef struct RelOptInfo
List *indexlist;
/* list of StatisticExtInfo */
List *statlist;
+ /* NOT NULL attributes offset by FirstLowInvalidHeapAttributeNumber */
+ Bitmapset *notnullattrs;
/* size estimates derived from pg_class */
BlockNumber pages;
Cardinality tuples;
--
2.35.1.windows.2
From ec42c5a6537d64071d08fb0f5f06f6321d1129c2 Mon Sep 17 00:00:00 2001
From: David Rowley <[email protected]>
Date: Thu, 7 Jul 2022 15:11:56 +1200
Subject: [PATCH v1 2/2] Don't add is NOT NULL clause to MinMaxAggInfo
transformed queries
... when the column is already non-NULLable.
This is not quite there yet. The fact that I had to shuffle
preprocess_minmax_aggregates() around makes me think it's wrong.
---
src/backend/optimizer/plan/planagg.c | 31 ++++++++++++++++-----------
src/backend/optimizer/plan/planmain.c | 8 +++++++
src/backend/optimizer/plan/planner.c | 9 --------
3 files changed, 27 insertions(+), 21 deletions(-)
diff --git a/src/backend/optimizer/plan/planagg.c b/src/backend/optimizer/plan/planagg.c
index 9330908cbf..afb3747acc 100644
--- a/src/backend/optimizer/plan/planagg.c
+++ b/src/backend/optimizer/plan/planagg.c
@@ -327,6 +327,7 @@ build_minmax_path(PlannerInfo *root, MinMaxAggInfo *mminfo,
Path *sorted_path;
Cost path_cost;
double path_fraction;
+ Var *var_target = (Var *) mminfo->target;
/*
* We are going to construct what is effectively a sub-SELECT query, so
@@ -382,18 +383,24 @@ build_minmax_path(PlannerInfo *root, MinMaxAggInfo *mminfo,
parse->hasDistinctOn = false;
parse->hasAggs = false;
- /* Build "target IS NOT NULL" expression */
- ntest = makeNode(NullTest);
- ntest->nulltesttype = IS_NOT_NULL;
- ntest->arg = copyObject(mminfo->target);
- /* we checked it wasn't a rowtype in find_minmax_aggs_walker */
- ntest->argisrow = false;
- ntest->location = -1;
-
- /* User might have had that in WHERE already */
- if (!list_member((List *) parse->jointree->quals, ntest))
- parse->jointree->quals = (Node *)
- lcons(ntest, (List *) parse->jointree->quals);
+ /* Check for non-Vars or NULLable Vars and add a NOT NULL tests */
+ if (!IsA(var_target, Var) ||
+ !bms_is_member(var_target->varattno - FirstLowInvalidHeapAttributeNumber,
+ root->simple_rel_array[var_target->varno]->notnullattrs))
+ {
+ /* Build "target IS NOT NULL" expression */
+ ntest = makeNode(NullTest);
+ ntest->nulltesttype = IS_NOT_NULL;
+ ntest->arg = copyObject(mminfo->target);
+ /* we checked it wasn't a rowtype in find_minmax_aggs_walker */
+ ntest->argisrow = false;
+ ntest->location = -1;
+
+ /* User might have had that in WHERE already */
+ if (!list_member((List *) parse->jointree->quals, ntest))
+ parse->jointree->quals = (Node *)
+ lcons(ntest, (List *) parse->jointree->quals);
+ }
/* Build suitable ORDER BY clause */
sortcl = makeNode(SortGroupClause);
diff --git a/src/backend/optimizer/plan/planmain.c b/src/backend/optimizer/plan/planmain.c
index c92ddd27ed..f375cac7fd 100644
--- a/src/backend/optimizer/plan/planmain.c
+++ b/src/backend/optimizer/plan/planmain.c
@@ -165,6 +165,14 @@ query_planner(PlannerInfo *root,
*/
add_base_rels_to_query(root, (Node *) parse->jointree);
+ /*
+ * Preprocess MIN/MAX aggregates, if any. XXX what are the actual
+ * repercussions of moving this out of grouping_planner() into
+ * query_planner()?
+ */
+ if (parse->hasAggs)
+ preprocess_minmax_aggregates(root);
+
/*
* Examine the targetlist and join tree, adding entries to baserel
* targetlists for all referenced Vars, and generating PlaceHolderInfo
diff --git a/src/backend/optimizer/plan/planner.c b/src/backend/optimizer/plan/planner.c
index 06ad856eac..f6c6c4b8b4 100644
--- a/src/backend/optimizer/plan/planner.c
+++ b/src/backend/optimizer/plan/planner.c
@@ -1425,15 +1425,6 @@ grouping_planner(PlannerInfo *root, double tuple_fraction)
parse->hasWindowFuncs = false;
}
- /*
- * Preprocess MIN/MAX aggregates, if any. Note: be careful about
- * adding logic between here and the query_planner() call. Anything
- * that is needed in MIN/MAX-optimizable cases will have to be
- * duplicated in planagg.c.
- */
- if (parse->hasAggs)
- preprocess_minmax_aggregates(root);
-
/*
* Figure out whether there's a hard limit on the number of rows that
* query_planner's result subplan needs to return. Even if we know a
--
2.35.1.windows.2
Attachments:
[text/plain] v1-0001-Track-NOT-NULL-columns-in-RelOptInfo-for-base-rel.patch (2.5K, ../../CAApHDvqhr1eU9v42w5gt_gL=G15pB9RBpAH_Jmg7eDU6iZ_2zg@mail.gmail.com/2-v1-0001-Track-NOT-NULL-columns-in-RelOptInfo-for-base-rel.patch)
download | inline diff:
From 0372cba1ea87d6eb10e21133461c1db525dbcf06 Mon Sep 17 00:00:00 2001
From: David Rowley <[email protected]>
Date: Thu, 7 Jul 2022 13:02:29 +1200
Subject: [PATCH v1 1/2] Track NOT NULL columns in RelOptInfo for base
relations
Author: Andy Fan
Discussion: https://postgr.es/m/CAKU4AWpUA8dyVSU1nfCJz71mu6VEjbGS1uy8azrt5CdyoZqGQA%40mail.gmail.com
---
src/backend/optimizer/util/plancat.c | 10 ++++++++++
src/backend/optimizer/util/relnode.c | 2 ++
src/include/nodes/pathnodes.h | 2 ++
3 files changed, 14 insertions(+)
diff --git a/src/backend/optimizer/util/plancat.c b/src/backend/optimizer/util/plancat.c
index 5012bfe142..7111284221 100644
--- a/src/backend/optimizer/util/plancat.c
+++ b/src/backend/optimizer/util/plancat.c
@@ -472,6 +472,16 @@ get_relation_info(PlannerInfo *root, Oid relationObjectId, bool inhparent,
if (inhparent && relation->rd_rel->relkind == RELKIND_PARTITIONED_TABLE)
set_relation_partition_info(root, rel, relation);
+ Assert(rel->notnullattrs == NULL);
+ for(int i = 0; i < relation->rd_att->natts; i++)
+ {
+ FormData_pg_attribute *attr = &relation->rd_att->attrs[i];
+
+ if (attr->attnotnull && !attr->attisdropped)
+ rel->notnullattrs = bms_add_member(rel->notnullattrs,
+ attr->attnum - FirstLowInvalidHeapAttributeNumber);
+ }
+
table_close(relation, NoLock);
/*
diff --git a/src/backend/optimizer/util/relnode.c b/src/backend/optimizer/util/relnode.c
index 520409f4ba..f7be6548ef 100644
--- a/src/backend/optimizer/util/relnode.c
+++ b/src/backend/optimizer/util/relnode.c
@@ -227,6 +227,7 @@ build_simple_rel(PlannerInfo *root, int relid, RelOptInfo *parent)
rel->lateral_vars = NIL;
rel->indexlist = NIL;
rel->statlist = NIL;
+ rel->notnullattrs = NULL;
rel->pages = 0;
rel->tuples = 0;
rel->allvisfrac = 0;
@@ -641,6 +642,7 @@ build_join_rel(PlannerInfo *root,
joinrel->lateral_referencers = NULL;
joinrel->indexlist = NIL;
joinrel->statlist = NIL;
+ joinrel->notnullattrs = NULL;
joinrel->pages = 0;
joinrel->tuples = 0;
joinrel->allvisfrac = 0;
diff --git a/src/include/nodes/pathnodes.h b/src/include/nodes/pathnodes.h
index b88cfb8dc0..5f81ecc3b5 100644
--- a/src/include/nodes/pathnodes.h
+++ b/src/include/nodes/pathnodes.h
@@ -758,6 +758,8 @@ typedef struct RelOptInfo
List *indexlist;
/* list of StatisticExtInfo */
List *statlist;
+ /* NOT NULL attributes offset by FirstLowInvalidHeapAttributeNumber */
+ Bitmapset *notnullattrs;
/* size estimates derived from pg_class */
BlockNumber pages;
Cardinality tuples;
--
2.35.1.windows.2
[text/plain] v1-0002-Don-t-add-is-NOT-NULL-clause-to-MinMaxAggInfo-tra.patch (4.0K, ../../CAApHDvqhr1eU9v42w5gt_gL=G15pB9RBpAH_Jmg7eDU6iZ_2zg@mail.gmail.com/3-v1-0002-Don-t-add-is-NOT-NULL-clause-to-MinMaxAggInfo-tra.patch)
download | inline diff:
From ec42c5a6537d64071d08fb0f5f06f6321d1129c2 Mon Sep 17 00:00:00 2001
From: David Rowley <[email protected]>
Date: Thu, 7 Jul 2022 15:11:56 +1200
Subject: [PATCH v1 2/2] Don't add is NOT NULL clause to MinMaxAggInfo
transformed queries
... when the column is already non-NULLable.
This is not quite there yet. The fact that I had to shuffle
preprocess_minmax_aggregates() around makes me think it's wrong.
---
src/backend/optimizer/plan/planagg.c | 31 ++++++++++++++++-----------
src/backend/optimizer/plan/planmain.c | 8 +++++++
src/backend/optimizer/plan/planner.c | 9 --------
3 files changed, 27 insertions(+), 21 deletions(-)
diff --git a/src/backend/optimizer/plan/planagg.c b/src/backend/optimizer/plan/planagg.c
index 9330908cbf..afb3747acc 100644
--- a/src/backend/optimizer/plan/planagg.c
+++ b/src/backend/optimizer/plan/planagg.c
@@ -327,6 +327,7 @@ build_minmax_path(PlannerInfo *root, MinMaxAggInfo *mminfo,
Path *sorted_path;
Cost path_cost;
double path_fraction;
+ Var *var_target = (Var *) mminfo->target;
/*
* We are going to construct what is effectively a sub-SELECT query, so
@@ -382,18 +383,24 @@ build_minmax_path(PlannerInfo *root, MinMaxAggInfo *mminfo,
parse->hasDistinctOn = false;
parse->hasAggs = false;
- /* Build "target IS NOT NULL" expression */
- ntest = makeNode(NullTest);
- ntest->nulltesttype = IS_NOT_NULL;
- ntest->arg = copyObject(mminfo->target);
- /* we checked it wasn't a rowtype in find_minmax_aggs_walker */
- ntest->argisrow = false;
- ntest->location = -1;
-
- /* User might have had that in WHERE already */
- if (!list_member((List *) parse->jointree->quals, ntest))
- parse->jointree->quals = (Node *)
- lcons(ntest, (List *) parse->jointree->quals);
+ /* Check for non-Vars or NULLable Vars and add a NOT NULL tests */
+ if (!IsA(var_target, Var) ||
+ !bms_is_member(var_target->varattno - FirstLowInvalidHeapAttributeNumber,
+ root->simple_rel_array[var_target->varno]->notnullattrs))
+ {
+ /* Build "target IS NOT NULL" expression */
+ ntest = makeNode(NullTest);
+ ntest->nulltesttype = IS_NOT_NULL;
+ ntest->arg = copyObject(mminfo->target);
+ /* we checked it wasn't a rowtype in find_minmax_aggs_walker */
+ ntest->argisrow = false;
+ ntest->location = -1;
+
+ /* User might have had that in WHERE already */
+ if (!list_member((List *) parse->jointree->quals, ntest))
+ parse->jointree->quals = (Node *)
+ lcons(ntest, (List *) parse->jointree->quals);
+ }
/* Build suitable ORDER BY clause */
sortcl = makeNode(SortGroupClause);
diff --git a/src/backend/optimizer/plan/planmain.c b/src/backend/optimizer/plan/planmain.c
index c92ddd27ed..f375cac7fd 100644
--- a/src/backend/optimizer/plan/planmain.c
+++ b/src/backend/optimizer/plan/planmain.c
@@ -165,6 +165,14 @@ query_planner(PlannerInfo *root,
*/
add_base_rels_to_query(root, (Node *) parse->jointree);
+ /*
+ * Preprocess MIN/MAX aggregates, if any. XXX what are the actual
+ * repercussions of moving this out of grouping_planner() into
+ * query_planner()?
+ */
+ if (parse->hasAggs)
+ preprocess_minmax_aggregates(root);
+
/*
* Examine the targetlist and join tree, adding entries to baserel
* targetlists for all referenced Vars, and generating PlaceHolderInfo
diff --git a/src/backend/optimizer/plan/planner.c b/src/backend/optimizer/plan/planner.c
index 06ad856eac..f6c6c4b8b4 100644
--- a/src/backend/optimizer/plan/planner.c
+++ b/src/backend/optimizer/plan/planner.c
@@ -1425,15 +1425,6 @@ grouping_planner(PlannerInfo *root, double tuple_fraction)
parse->hasWindowFuncs = false;
}
- /*
- * Preprocess MIN/MAX aggregates, if any. Note: be careful about
- * adding logic between here and the query_planner() call. Anything
- * that is needed in MIN/MAX-optimizable cases will have to be
- * duplicated in planagg.c.
- */
- if (parse->hasAggs)
- preprocess_minmax_aggregates(root);
-
/*
* Figure out whether there's a hard limit on the number of rows that
* query_planner's result subplan needs to return. Even if we know a
--
2.35.1.windows.2
^ permalink raw reply [nested|flat] 54+ messages in thread
* Re: BUG #17540: Prepared statement: PG switches to a generic query plan which is consistently much slower
@ 2022-07-07 03:50 Tom Lane <[email protected]>
parent: David Rowley <[email protected]>
0 siblings, 0 replies; 54+ messages in thread
From: Tom Lane @ 2022-07-07 03:50 UTC (permalink / raw)
To: David Rowley <[email protected]>; +Cc: [email protected]; PostgreSQL mailing lists <[email protected]>
David Rowley <[email protected]> writes:
> Anyway, I've no current plans to take the attached any further. I
> think it'll be better to pursue your NULLable-Var stuff and see if we
> can do something more generic like remove provably redundant NullTests
> from baserestrictinfo.
Yeah, I suspect that the way forward is to allow
preprocess_minmax_aggregates to do what it does now, and then
remove the IS NOT NULL clause again later when we have the
info available to let us do that in a generic way.
In any case, as you said, it's just a band-aid that happens to
help in this exact scenario. It's not doing much for the bad
cost estimation that's the root of the problem.
regards, tom lane
^ permalink raw reply [nested|flat] 54+ messages in thread
* Re: BUG #17540: Prepared statement: PG switches to a generic query plan which is consistently much slower
@ 2022-07-07 04:36 Andres Freund <[email protected]>
parent: Tom Lane <[email protected]>
0 siblings, 1 reply; 54+ messages in thread
From: Andres Freund @ 2022-07-07 04:36 UTC (permalink / raw)
To: Tom Lane <[email protected]>; +Cc: David G. Johnston <[email protected]>; [email protected]; PostgreSQL mailing lists <[email protected]>
Hi,
On 2022-07-06 23:13:18 -0400, Tom Lane wrote:
> Andres Freund <[email protected]> writes:
> > I think the cost for the slow plan being so much cheaper can almost be
> > qualified as bug.
> > The slow plan seems pretty nonsensical to me. ISTM that something in the
> > costing there is at least almost broken.
>
> I think this is probably an instance of the known problem that a generic
> plan is made without knowledge of the actual parameter values, and that
> can lead us to make statistical assumptions that are not valid for the
> actual values, but nonetheless make one plan look cheaper than another
> even though the opposite is true given the actual values. In essence,
> comparing the cost estimate for the generic plan to the cost estimate
> for a custom plan is not really logically valid, because those estimates
> are founded on different statistics. I don't know how to fix that :-(.
I think there's something more fundamentally wrong - somehow we end up with
assuming > 50% selectivity on both the min and the max initplan, for the same
condition! And afaics (although it's a bit hard to see with the precision
explain prints floating point values as) don't charge cpu_operator_cost /
cpu_tuple_cost. And this is on a table where we can know, despite not know the
parameter value, that the column being compared has a correlation of 1.
In this case the whole generic plan part seems like a red herring. The generic
plan is *awful* and would still be awful if the value were known, but
somewhere around the middle of the value range.
Here's the op's tables + query, but without the prepared statement part:
CREATE TABLE relation_tuple_transaction (
id BIGSERIAL NOT NULL UNIQUE,
timestamp TIMESTAMP WITHOUT TIME ZONE NOT NULL UNIQUE,
CONSTRAINT pk_rttx PRIMARY KEY (id)
);
CREATE INDEX ix_relation_tuple_transaction_by_timestamp on relation_tuple_transaction(timestamp);
INSERT INTO relation_tuple_transaction(timestamp) SELECT * FROM generate_series
( now() - interval '3 days'
, now()
, '1 second'::interval) dd
;
vacuum freeze analyze;
EXPLAIN ANALYZE SELECT MIN(id), MAX(id) from relation_tuple_transaction WHERE timestamp >= (now() - interval '1.5 days');
postgres[631148][1]=# EXPLAIN ANALYZE SELECT MIN(id), MAX(id) from relation_tuple_transaction WHERE timestamp >= (now() - interval '1.5 days');;
Result (cost=1.01..1.02 rows=1 width=16) (actual time=113.379..113.381 rows=1 loops=1)
InitPlan 1 (returns $0)
-> Limit (cost=0.42..0.50 rows=1 width=8) (actual time=113.347..113.348 rows=1 loops=1)
-> Index Scan using pk_rttx on relation_tuple_transaction (cost=0.42..10741.45 rows=127009 width=8) (actual time=113.345..113.345 rows=1 loops=1)
Index Cond: (id IS NOT NULL)
Filter: ("timestamp" >= (now() - '1 day 12:00:00'::interval))
Rows Removed by Filter: 129746
InitPlan 2 (returns $1)
-> Limit (cost=0.42..0.50 rows=1 width=8) (actual time=0.024..0.024 rows=1 loops=1)
-> Index Scan Backward using pk_rttx on relation_tuple_transaction relation_tuple_transaction_1 (cost=0.42..10741.45 rows=127009 width=8) (actual time=0.023..0.023 rows=1 loops=1)
Index Cond: (id IS NOT NULL)
Filter: ("timestamp" >= (now() - '1 day 12:00:00'::interval))
Planning Time: 0.370 ms
Execution Time: 113.441 ms
(14 rows)
We're pretty much by definition scanning half the table via the index scans,
and end up with a cost of 1.02 (yes, aware that the paths are costed
separately).
FWIW, manually writing the min/max as ORDER BY timestamp ASC/DESC LIMIT 1
queries yields a *vastly* better plan:
EXPLAIN ANALYZE SELECT (SELECT id FROM relation_tuple_transaction WHERE timestamp >= (now() - interval '1.5 days') ORDER BY timestamp ASC LIMIT 1), (SELECT id FROM relation_tuple_transaction WHERE timestamp >= (now() - interval '1.5 days') ORDER BY timestamp DESC LIMIT 1);
Result (cost=0.92..0.93 rows=1 width=16) (actual time=0.110..0.111 rows=1 loops=1)
InitPlan 1 (returns $0)
-> Limit (cost=0.42..0.46 rows=1 width=16) (actual time=0.079..0.079 rows=1 loops=1)
-> Index Scan using ix_relation_tuple_transaction_by_timestamp on relation_tuple_transaction (cost=0.42..4405.46 rows=129602 width=16) (actual time=0.077..0.078 rows=1 loops=1)
Index Cond: ("timestamp" >= (now() - '1 day 12:00:00'::interval))
InitPlan 2 (returns $1)
-> Limit (cost=0.42..0.46 rows=1 width=16) (actual time=0.028..0.028 rows=1 loops=1)
-> Index Scan Backward using ix_relation_tuple_transaction_by_timestamp on relation_tuple_transaction relation_tuple_transaction_1 (cost=0.42..4405.46 rows=129602 width=16) (actual time=0.027..0.027 rows=1 loops=1)
Index Cond: ("timestamp" >= (now() - '1 day 12:00:00'::interval))
Planning Time: 0.270 ms
Execution Time: 0.159 ms (11 rows)
And it stays sane even if you add a (redundantly evaluated) AND id IS NOT NULL.
EXPLAIN SELECT id FROM relation_tuple_transaction WHERE timestamp >= (now() - interval '1.5 days') AND id IS NOT NULL ORDER BY timestamp ASC LIMIT 1;
QUERY PLAN
Limit (cost=0.42..0.46 rows=1 width=16)
-> Index Scan using ix_relation_tuple_transaction_by_timestamp on relation_tuple_transaction (cost=0.42..4405.46 rows=129602 width=16)
Index Cond: ("timestamp" >= (now() - '1 day 12:00:00'::interval))
Filter: (id IS NOT NULL)
(4 rows)
EXPLAIN SELECT min(id) FROM relation_tuple_transaction WHERE timestamp >= (now() - interval '1.5 days');
QUERY PLAN
Result (cost=0.50..0.51 rows=1 width=8)
InitPlan 1 (returns $0)
-> Limit (cost=0.42..0.50 rows=1 width=8)
-> Index Scan using pk_rttx on relation_tuple_transaction (cost=0.42..10741.45 rows=129602 width=8)
Index Cond: (id IS NOT NULL)
Filter: ("timestamp" >= (now() - '1 day 12:00:00'::interval))
(6 rows)
Greetings,
Andres Freund
^ permalink raw reply [nested|flat] 54+ messages in thread
* Re: BUG #17540: Prepared statement: PG switches to a generic query plan which is consistently much slower
@ 2022-07-07 18:02 Tom Lane <[email protected]>
parent: Andres Freund <[email protected]>
0 siblings, 0 replies; 54+ messages in thread
From: Tom Lane @ 2022-07-07 18:02 UTC (permalink / raw)
To: Andres Freund <[email protected]>; +Cc: David G. Johnston <[email protected]>; [email protected]; PostgreSQL mailing lists <[email protected]>
Andres Freund <[email protected]> writes:
> On 2022-07-06 23:13:18 -0400, Tom Lane wrote:
>> comparing the cost estimate for the generic plan to the cost estimate
>> for a custom plan is not really logically valid, because those estimates
>> are founded on different statistics. I don't know how to fix that :-(.
> I think there's something more fundamentally wrong - somehow we end up with
> assuming > 50% selectivity on both the min and the max initplan, for the same
> condition!
Well, sure, because it *is* the same condition. AFAICS this is operating
as designed. Do I wish it were better? Sure, but there is no simple fix
here.
The reasoning that's being applied in the generic plan is
(1) default selectivity estimate for a scalar inequality is
#define DEFAULT_INEQ_SEL 0.3333333333333333
(2) therefore, the filter condition on the indexscan will select a random
one-third of the table;
(3) therefore, the LIMIT will be able to stop after about three rows,
whichever direction we scan in.
The information that is lacking is that the "id" and "timestamp"
columns are heavily correlated, so that we may have to scan far more
than three rows in "id" order before finding a row satisfying the
inequality on "timestamp". This is a problem we've understood for
a long time --- I recall talking about it at PGCon a decade ago.
The extended stats machinery provides a framework wherein we could
calculate and save the ordering correlation between the two columns,
but I don't believe it actually calculates that number yet --- I think
the functional-dependency stuff is close but not the right thing.
Even if we had the stats, it's not very clear where to fit this
type of consideration into the planner's estimates.
> In this case the whole generic plan part seems like a red herring. The generic
> plan is *awful* and would still be awful if the value were known, but
> somewhere around the middle of the value range.
If the value were somewhere around the middle (which is more or less
what we're assuming for the generic plan), then an indexscan on the
timestamp column isn't going to be that great either; you'd still
be scanning half the table.
> FWIW, manually writing the min/max as ORDER BY timestamp ASC/DESC LIMIT 1
> queries yields a *vastly* better plan:
Those queries give the wrong answers. We're looking for the min or max
id, not the id associated with the min or max timestamp. (They're
accidentally the same with this toy dataset.)
regards, tom lane
^ permalink raw reply [nested|flat] 54+ messages in thread
end of thread, other threads:[~2022-07-07 18:02 UTC | newest]
Thread overview: 54+ messages (download: mbox mbox.gz follow: Atom feed)
-- links below jump to the message on this page --
2021-01-07 01:08 [PATCH] doc review: COPY progress: 8a4f618e7ae3cb11b0b37d0f06f05c8ff905833f Justin Pryzby <[email protected]>
2021-01-07 01:08 [PATCH] doc review: COPY progress: 8a4f618e7ae3cb11b0b37d0f06f05c8ff905833f Justin Pryzby <[email protected]>
2021-01-07 01:08 [PATCH] doc review: COPY progress: 8a4f618e7ae3cb11b0b37d0f06f05c8ff905833f Justin Pryzby <[email protected]>
2021-01-07 01:08 [PATCH] doc review: COPY progress: 8a4f618e7ae3cb11b0b37d0f06f05c8ff905833f Justin Pryzby <[email protected]>
2021-01-07 01:08 [PATCH] doc review: COPY progress: 8a4f618e7ae3cb11b0b37d0f06f05c8ff905833f Justin Pryzby <[email protected]>
2021-01-07 01:08 [PATCH] doc review: COPY progress: 8a4f618e7ae3cb11b0b37d0f06f05c8ff905833f Justin Pryzby <[email protected]>
2021-01-07 01:08 [PATCH] doc review: COPY progress: 8a4f618e7ae3cb11b0b37d0f06f05c8ff905833f Justin Pryzby <[email protected]>
2021-01-07 01:08 [PATCH] doc review: COPY progress: 8a4f618e7ae3cb11b0b37d0f06f05c8ff905833f Justin Pryzby <[email protected]>
2021-01-07 01:08 [PATCH] doc review: COPY progress: 8a4f618e7ae3cb11b0b37d0f06f05c8ff905833f Justin Pryzby <[email protected]>
2021-01-07 01:08 [PATCH] doc review: COPY progress: 8a4f618e7ae3cb11b0b37d0f06f05c8ff905833f Justin Pryzby <[email protected]>
2021-01-07 01:08 [PATCH] doc review: COPY progress: 8a4f618e7ae3cb11b0b37d0f06f05c8ff905833f Justin Pryzby <[email protected]>
2021-01-07 01:08 [PATCH] doc review: COPY progress: 8a4f618e7ae3cb11b0b37d0f06f05c8ff905833f Justin Pryzby <[email protected]>
2021-01-07 01:08 [PATCH] doc review: COPY progress: 8a4f618e7ae3cb11b0b37d0f06f05c8ff905833f Justin Pryzby <[email protected]>
2021-01-07 01:08 [PATCH] doc review: COPY progress: 8a4f618e7ae3cb11b0b37d0f06f05c8ff905833f Justin Pryzby <[email protected]>
2021-01-07 01:08 [PATCH] doc review: COPY progress: 8a4f618e7ae3cb11b0b37d0f06f05c8ff905833f Justin Pryzby <[email protected]>
2021-01-07 01:08 [PATCH] doc review: COPY progress: 8a4f618e7ae3cb11b0b37d0f06f05c8ff905833f Justin Pryzby <[email protected]>
2021-01-07 01:08 [PATCH] doc review: COPY progress: 8a4f618e7ae3cb11b0b37d0f06f05c8ff905833f Justin Pryzby <[email protected]>
2021-01-07 01:08 [PATCH] doc review: COPY progress: 8a4f618e7ae3cb11b0b37d0f06f05c8ff905833f Justin Pryzby <[email protected]>
2021-01-07 01:08 [PATCH] doc review: COPY progress: 8a4f618e7ae3cb11b0b37d0f06f05c8ff905833f Justin Pryzby <[email protected]>
2021-01-07 01:08 [PATCH] doc review: COPY progress: 8a4f618e7ae3cb11b0b37d0f06f05c8ff905833f Justin Pryzby <[email protected]>
2021-01-07 01:08 [PATCH] doc review: COPY progress: 8a4f618e7ae3cb11b0b37d0f06f05c8ff905833f Justin Pryzby <[email protected]>
2021-01-07 01:08 [PATCH] doc review: COPY progress: 8a4f618e7ae3cb11b0b37d0f06f05c8ff905833f Justin Pryzby <[email protected]>
2021-01-07 01:08 [PATCH] doc review: COPY progress: 8a4f618e7ae3cb11b0b37d0f06f05c8ff905833f Justin Pryzby <[email protected]>
2021-01-07 01:08 [PATCH] doc review: COPY progress: 8a4f618e7ae3cb11b0b37d0f06f05c8ff905833f Justin Pryzby <[email protected]>
2021-01-07 01:08 [PATCH] doc review: COPY progress: 8a4f618e7ae3cb11b0b37d0f06f05c8ff905833f Justin Pryzby <[email protected]>
2021-01-07 01:08 [PATCH] doc review: COPY progress: 8a4f618e7ae3cb11b0b37d0f06f05c8ff905833f Justin Pryzby <[email protected]>
2021-01-07 01:08 [PATCH] doc review: COPY progress: 8a4f618e7ae3cb11b0b37d0f06f05c8ff905833f Justin Pryzby <[email protected]>
2021-01-07 01:08 [PATCH] doc review: COPY progress: 8a4f618e7ae3cb11b0b37d0f06f05c8ff905833f Justin Pryzby <[email protected]>
2021-01-07 01:08 [PATCH] doc review: COPY progress: 8a4f618e7ae3cb11b0b37d0f06f05c8ff905833f Justin Pryzby <[email protected]>
2021-01-07 01:08 [PATCH] doc review: COPY progress: 8a4f618e7ae3cb11b0b37d0f06f05c8ff905833f Justin Pryzby <[email protected]>
2021-01-07 01:08 [PATCH] doc review: COPY progress: 8a4f618e7ae3cb11b0b37d0f06f05c8ff905833f Justin Pryzby <[email protected]>
2021-01-07 01:08 [PATCH] doc review: COPY progress: 8a4f618e7ae3cb11b0b37d0f06f05c8ff905833f Justin Pryzby <[email protected]>
2021-01-07 01:08 [PATCH] doc review: COPY progress: 8a4f618e7ae3cb11b0b37d0f06f05c8ff905833f Justin Pryzby <[email protected]>
2021-01-07 01:08 [PATCH] doc review: COPY progress: 8a4f618e7ae3cb11b0b37d0f06f05c8ff905833f Justin Pryzby <[email protected]>
2021-01-07 01:08 [PATCH] doc review: COPY progress: 8a4f618e7ae3cb11b0b37d0f06f05c8ff905833f Justin Pryzby <[email protected]>
2021-01-07 01:08 [PATCH] doc review: COPY progress: 8a4f618e7ae3cb11b0b37d0f06f05c8ff905833f Justin Pryzby <[email protected]>
2021-01-07 01:08 [PATCH] doc review: COPY progress: 8a4f618e7ae3cb11b0b37d0f06f05c8ff905833f Justin Pryzby <[email protected]>
2021-01-07 01:08 [PATCH] doc review: COPY progress: 8a4f618e7ae3cb11b0b37d0f06f05c8ff905833f Justin Pryzby <[email protected]>
2021-01-07 01:08 [PATCH] doc review: COPY progress: 8a4f618e7ae3cb11b0b37d0f06f05c8ff905833f Justin Pryzby <[email protected]>
2021-01-07 01:08 [PATCH] doc review: COPY progress: 8a4f618e7ae3cb11b0b37d0f06f05c8ff905833f Justin Pryzby <[email protected]>
2021-01-07 01:08 [PATCH] doc review: COPY progress: 8a4f618e7ae3cb11b0b37d0f06f05c8ff905833f Justin Pryzby <[email protected]>
2021-01-07 01:08 [PATCH] doc review: COPY progress: 8a4f618e7ae3cb11b0b37d0f06f05c8ff905833f Justin Pryzby <[email protected]>
2022-07-05 22:13 BUG #17540: Prepared statement: PG switches to a generic query plan which is consistently much slower PG Bug reporting form <[email protected]>
2022-07-06 22:07 ` Re: BUG #17540: Prepared statement: PG switches to a generic query plan which is consistently much slower David G. Johnston <[email protected]>
2022-07-07 00:46 ` Re: BUG #17540: Prepared statement: PG switches to a generic query plan which is consistently much slower Andres Freund <[email protected]>
2022-07-07 01:54 ` Re: BUG #17540: Prepared statement: PG switches to a generic query plan which is consistently much slower David Rowley <[email protected]>
2022-07-07 03:13 ` Re: BUG #17540: Prepared statement: PG switches to a generic query plan which is consistently much slower Tom Lane <[email protected]>
2022-07-07 04:36 ` Re: BUG #17540: Prepared statement: PG switches to a generic query plan which is consistently much slower Andres Freund <[email protected]>
2022-07-07 18:02 ` Re: BUG #17540: Prepared statement: PG switches to a generic query plan which is consistently much slower Tom Lane <[email protected]>
2022-07-07 00:23 ` Re: BUG #17540: Prepared statement: PG switches to a generic query plan which is consistently much slower David Rowley <[email protected]>
2022-07-07 00:46 ` Re: BUG #17540: Prepared statement: PG switches to a generic query plan which is consistently much slower David Rowley <[email protected]>
2022-07-07 03:06 ` Re: BUG #17540: Prepared statement: PG switches to a generic query plan which is consistently much slower Tom Lane <[email protected]>
2022-07-07 03:31 ` Re: BUG #17540: Prepared statement: PG switches to a generic query plan which is consistently much slower David Rowley <[email protected]>
2022-07-07 03:50 ` Re: BUG #17540: Prepared statement: PG switches to a generic query plan which is consistently much slower Tom Lane <[email protected]>
This inbox is served by agora; see mirroring instructions
for how to clone and mirror all data and code used for this inbox