public inbox for [email protected]help / color / mirror / Atom feed
[PATCH v3] Add "Backpatch" regions in wait_event_names.txt 21+ messages / 5 participants [nested] [flat]
* [PATCH v3] Add "Backpatch" regions in wait_event_names.txt @ 2024-03-18 08:34 Bertrand Drouvot <[email protected]> 0 siblings, 0 replies; 21+ messages in thread From: Bertrand Drouvot @ 2024-03-18 08:34 UTC (permalink / raw) When backpatching, adding an event will renumber others, which can make an extension report the wrong event until recompiled. This is due to the fact that generate-wait_event_types.pl sorts events to position them. The "Backpatch" region added here ensures no ordering is done for the wait events found after this delimiter. --- .../activity/generate-wait_event_types.pl | 26 ++++++++++++++++++- .../utils/activity/wait_event_names.txt | 18 ++++++++++++- 2 files changed, 42 insertions(+), 2 deletions(-) 100.0% src/backend/utils/activity/ diff --git a/src/backend/utils/activity/generate-wait_event_types.pl b/src/backend/utils/activity/generate-wait_event_types.pl index f1adf0e8e7..d129d94889 100644 --- a/src/backend/utils/activity/generate-wait_event_types.pl +++ b/src/backend/utils/activity/generate-wait_event_types.pl @@ -38,7 +38,9 @@ die "Not possible to specify --docs and --code simultaneously" open my $wait_event_names, '<', $ARGV[0] or die; +my @backpatch_lines; my @lines; +my $backpatch = 0; my $section_name; my $note; my $note_name; @@ -59,10 +61,26 @@ while (<$wait_event_names>) { $section_name = $_; $section_name =~ s/^.*- //; + $backpatch = 0; next; } - push(@lines, $section_name . "\t" . $_); + # Are we dealing with backpatch wait events? + if (/^Backpatch:$/) + { + $backpatch = 1; + next; + } + + # Backpatch wait events won't be sorted during code generation + if ($gen_code && $backpatch) + { + push(@backpatch_lines, $section_name . "\t" . $_); + } + else + { + push(@lines, $section_name . "\t" . $_); + } } # Sort the lines based on the second column. @@ -70,6 +88,12 @@ while (<$wait_event_names>) my @lines_sorted = sort { uc((split(/\t/, $a))[1]) cmp uc((split(/\t/, $b))[1]) } @lines; +# If we are generating code then concat @lines_sorted and @backpatch_lines. +if ($gen_code) +{ + push(@lines_sorted, @backpatch_lines); +} + # Read the sorted lines and populate the hash table foreach my $line (@lines_sorted) { diff --git a/src/backend/utils/activity/wait_event_names.txt b/src/backend/utils/activity/wait_event_names.txt index c08e00d1d6..0c4788fe77 100644 --- a/src/backend/utils/activity/wait_event_names.txt +++ b/src/backend/utils/activity/wait_event_names.txt @@ -24,7 +24,10 @@ # SGML tables of wait events for inclusion in the documentation. # # When adding a new wait event, make sure it is placed in the appropriate -# ClassName section. +# ClassName section. Put it in its natural position in the master branch, and +# then put it in the "Backpatch:" region for any other branch (should the wait +# event be backpatched). +# Ensure that the backpatch regions are always empty on the master branch. # # WaitEventLWLock and WaitEventLock have their own C code for their wait event # enums and function names. Hence, for these, only the SGML documentation is @@ -61,6 +64,7 @@ WAL_SENDER_MAIN "Waiting in main loop of WAL sender process." WAL_SUMMARIZER_WAL "Waiting in WAL summarizer for more WAL to be generated." WAL_WRITER_MAIN "Waiting in main loop of WAL writer process." +Backpatch: # # Wait Events - Client @@ -82,6 +86,7 @@ WAIT_FOR_STANDBY_CONFIRMATION "Waiting for WAL to be received and flushed by the WAL_SENDER_WAIT_FOR_WAL "Waiting for WAL to be flushed in WAL sender process." WAL_SENDER_WRITE_DATA "Waiting for any activity when processing replies from WAL receiver in WAL sender process." +Backpatch: # # Wait Events - IPC @@ -149,6 +154,7 @@ WAL_RECEIVER_WAIT_START "Waiting for startup process to send initial data for st WAL_SUMMARY_READY "Waiting for a new WAL summary to be generated." XACT_GROUP_UPDATE "Waiting for the group leader to update transaction status at end of a parallel operation." +Backpatch: # # Wait Events - Timeout @@ -169,6 +175,7 @@ VACUUM_DELAY "Waiting in a cost-based vacuum delay point." VACUUM_TRUNCATE "Waiting to acquire an exclusive lock to truncate off any empty pages at the end of a table vacuumed." WAL_SUMMARIZER_ERROR "Waiting after a WAL summarizer error." +Backpatch: # # Wait Events - IO @@ -256,6 +263,7 @@ WAL_SYNC "Waiting for a WAL file to reach durable storage." WAL_SYNC_METHOD_ASSIGN "Waiting for data to reach durable storage while assigning a new WAL sync method." WAL_WRITE "Waiting for a write to a WAL file." +Backpatch: # # Wait Events - Buffer Pin @@ -265,6 +273,7 @@ Section: ClassName - WaitEventBufferPin BUFFER_PIN "Waiting to acquire an exclusive pin on a buffer." +Backpatch: # # Wait Events - Extension @@ -274,6 +283,8 @@ Section: ClassName - WaitEventExtension Extension "Waiting in an extension." +Backpatch: + # # Wait Events - LWLock # @@ -330,6 +341,8 @@ DSMRegistry "Waiting to read or update the dynamic shared memory registry." InjectionPoint "Waiting to read or update information related to injection points." SerialControl "Waiting to read or update shared <filename>pg_serial</filename> state." +# Don't create a Backpatch region here. + # # END OF PREDEFINED LWLOCKS (DO NOT CHANGE THIS LINE) # @@ -377,6 +390,7 @@ SerialSLRU "Waiting to access the serializable transaction conflict SLRU cache." SubtransSLRU "Waiting to access the sub-transaction SLRU cache." XactSLRU "Waiting to access the transaction status SLRU cache." +# Don't create a Backpatch region here. # # Wait Events - Lock @@ -399,3 +413,5 @@ object "Waiting to acquire a lock on a non-relation database object." userlock "Waiting to acquire a user lock." advisory "Waiting to acquire an advisory user lock." applytransaction "Waiting to acquire a lock on a remote transaction being applied by a logical replication subscriber." + +Backpatch: -- 2.34.1 --m1fyrkxSXqjY+FO1-- ^ permalink raw reply [nested|flat] 21+ messages in thread
* [PATCH v2] Add "Backpatch" regions in wait_event_names.txt @ 2024-03-18 08:34 Bertrand Drouvot <[email protected]> 0 siblings, 0 replies; 21+ messages in thread From: Bertrand Drouvot @ 2024-03-18 08:34 UTC (permalink / raw) When backpatching, adding an event will renumber others, which can make an extension report the wrong event until recompiled. This is due to the fact that generate-wait_event_types.pl sorts events to position them. The "Backpatch" region added here ensures no ordering is done for the wait events found after this delimiter. --- .../activity/generate-wait_event_types.pl | 26 ++++++++++++++++++- .../utils/activity/wait_event_names.txt | 19 +++++++++++++- 2 files changed, 43 insertions(+), 2 deletions(-) 100.0% src/backend/utils/activity/ diff --git a/src/backend/utils/activity/generate-wait_event_types.pl b/src/backend/utils/activity/generate-wait_event_types.pl index f1adf0e8e7..d129d94889 100644 --- a/src/backend/utils/activity/generate-wait_event_types.pl +++ b/src/backend/utils/activity/generate-wait_event_types.pl @@ -38,7 +38,9 @@ die "Not possible to specify --docs and --code simultaneously" open my $wait_event_names, '<', $ARGV[0] or die; +my @backpatch_lines; my @lines; +my $backpatch = 0; my $section_name; my $note; my $note_name; @@ -59,10 +61,26 @@ while (<$wait_event_names>) { $section_name = $_; $section_name =~ s/^.*- //; + $backpatch = 0; next; } - push(@lines, $section_name . "\t" . $_); + # Are we dealing with backpatch wait events? + if (/^Backpatch:$/) + { + $backpatch = 1; + next; + } + + # Backpatch wait events won't be sorted during code generation + if ($gen_code && $backpatch) + { + push(@backpatch_lines, $section_name . "\t" . $_); + } + else + { + push(@lines, $section_name . "\t" . $_); + } } # Sort the lines based on the second column. @@ -70,6 +88,12 @@ while (<$wait_event_names>) my @lines_sorted = sort { uc((split(/\t/, $a))[1]) cmp uc((split(/\t/, $b))[1]) } @lines; +# If we are generating code then concat @lines_sorted and @backpatch_lines. +if ($gen_code) +{ + push(@lines_sorted, @backpatch_lines); +} + # Read the sorted lines and populate the hash table foreach my $line (@lines_sorted) { diff --git a/src/backend/utils/activity/wait_event_names.txt b/src/backend/utils/activity/wait_event_names.txt index c08e00d1d6..b6303a0fdb 100644 --- a/src/backend/utils/activity/wait_event_names.txt +++ b/src/backend/utils/activity/wait_event_names.txt @@ -24,7 +24,11 @@ # SGML tables of wait events for inclusion in the documentation. # # When adding a new wait event, make sure it is placed in the appropriate -# ClassName section. +# ClassName section. If the wait event is backpatched from master to a version +# >= 17 then put it under a "Backpatch:" delimiter at the end of the related +# ClassName section (on the non master branches) or at its natural position on +# the master branch. +# Ensure that the backpatch regions are always empty on the master branch. # # WaitEventLWLock and WaitEventLock have their own C code for their wait event # enums and function names. Hence, for these, only the SGML documentation is @@ -61,6 +65,7 @@ WAL_SENDER_MAIN "Waiting in main loop of WAL sender process." WAL_SUMMARIZER_WAL "Waiting in WAL summarizer for more WAL to be generated." WAL_WRITER_MAIN "Waiting in main loop of WAL writer process." +Backpatch: # # Wait Events - Client @@ -82,6 +87,7 @@ WAIT_FOR_STANDBY_CONFIRMATION "Waiting for WAL to be received and flushed by the WAL_SENDER_WAIT_FOR_WAL "Waiting for WAL to be flushed in WAL sender process." WAL_SENDER_WRITE_DATA "Waiting for any activity when processing replies from WAL receiver in WAL sender process." +Backpatch: # # Wait Events - IPC @@ -149,6 +155,7 @@ WAL_RECEIVER_WAIT_START "Waiting for startup process to send initial data for st WAL_SUMMARY_READY "Waiting for a new WAL summary to be generated." XACT_GROUP_UPDATE "Waiting for the group leader to update transaction status at end of a parallel operation." +Backpatch: # # Wait Events - Timeout @@ -169,6 +176,7 @@ VACUUM_DELAY "Waiting in a cost-based vacuum delay point." VACUUM_TRUNCATE "Waiting to acquire an exclusive lock to truncate off any empty pages at the end of a table vacuumed." WAL_SUMMARIZER_ERROR "Waiting after a WAL summarizer error." +Backpatch: # # Wait Events - IO @@ -256,6 +264,7 @@ WAL_SYNC "Waiting for a WAL file to reach durable storage." WAL_SYNC_METHOD_ASSIGN "Waiting for data to reach durable storage while assigning a new WAL sync method." WAL_WRITE "Waiting for a write to a WAL file." +Backpatch: # # Wait Events - Buffer Pin @@ -265,6 +274,7 @@ Section: ClassName - WaitEventBufferPin BUFFER_PIN "Waiting to acquire an exclusive pin on a buffer." +Backpatch: # # Wait Events - Extension @@ -274,6 +284,8 @@ Section: ClassName - WaitEventExtension Extension "Waiting in an extension." +Backpatch: + # # Wait Events - LWLock # @@ -330,6 +342,8 @@ DSMRegistry "Waiting to read or update the dynamic shared memory registry." InjectionPoint "Waiting to read or update information related to injection points." SerialControl "Waiting to read or update shared <filename>pg_serial</filename> state." +# Don't create a Backpatch region here. + # # END OF PREDEFINED LWLOCKS (DO NOT CHANGE THIS LINE) # @@ -377,6 +391,7 @@ SerialSLRU "Waiting to access the serializable transaction conflict SLRU cache." SubtransSLRU "Waiting to access the sub-transaction SLRU cache." XactSLRU "Waiting to access the transaction status SLRU cache." +# Don't create a Backpatch region here. # # Wait Events - Lock @@ -399,3 +414,5 @@ object "Waiting to acquire a lock on a non-relation database object." userlock "Waiting to acquire a user lock." advisory "Waiting to acquire an advisory user lock." applytransaction "Waiting to acquire a lock on a remote transaction being applied by a logical replication subscriber." + +Backpatch: -- 2.34.1 --Xg/TgUq/K7vNmQT2-- ^ permalink raw reply [nested|flat] 21+ messages in thread
* [PATCH v2] Add "Backpatch" regions in wait_event_names.txt @ 2024-03-18 08:34 Bertrand Drouvot <[email protected]> 0 siblings, 0 replies; 21+ messages in thread From: Bertrand Drouvot @ 2024-03-18 08:34 UTC (permalink / raw) When backpatching, adding an event will renumber others, which can make an extension report the wrong event until recompiled. This is due to the fact that generate-wait_event_types.pl sorts events to position them. The "Backpatch" region added here ensures no ordering is done for the wait events found after this delimiter. --- .../activity/generate-wait_event_types.pl | 26 ++++++++++++++++++- .../utils/activity/wait_event_names.txt | 19 +++++++++++++- 2 files changed, 43 insertions(+), 2 deletions(-) 100.0% src/backend/utils/activity/ diff --git a/src/backend/utils/activity/generate-wait_event_types.pl b/src/backend/utils/activity/generate-wait_event_types.pl index f1adf0e8e7..d129d94889 100644 --- a/src/backend/utils/activity/generate-wait_event_types.pl +++ b/src/backend/utils/activity/generate-wait_event_types.pl @@ -38,7 +38,9 @@ die "Not possible to specify --docs and --code simultaneously" open my $wait_event_names, '<', $ARGV[0] or die; +my @backpatch_lines; my @lines; +my $backpatch = 0; my $section_name; my $note; my $note_name; @@ -59,10 +61,26 @@ while (<$wait_event_names>) { $section_name = $_; $section_name =~ s/^.*- //; + $backpatch = 0; next; } - push(@lines, $section_name . "\t" . $_); + # Are we dealing with backpatch wait events? + if (/^Backpatch:$/) + { + $backpatch = 1; + next; + } + + # Backpatch wait events won't be sorted during code generation + if ($gen_code && $backpatch) + { + push(@backpatch_lines, $section_name . "\t" . $_); + } + else + { + push(@lines, $section_name . "\t" . $_); + } } # Sort the lines based on the second column. @@ -70,6 +88,12 @@ while (<$wait_event_names>) my @lines_sorted = sort { uc((split(/\t/, $a))[1]) cmp uc((split(/\t/, $b))[1]) } @lines; +# If we are generating code then concat @lines_sorted and @backpatch_lines. +if ($gen_code) +{ + push(@lines_sorted, @backpatch_lines); +} + # Read the sorted lines and populate the hash table foreach my $line (@lines_sorted) { diff --git a/src/backend/utils/activity/wait_event_names.txt b/src/backend/utils/activity/wait_event_names.txt index c08e00d1d6..b6303a0fdb 100644 --- a/src/backend/utils/activity/wait_event_names.txt +++ b/src/backend/utils/activity/wait_event_names.txt @@ -24,7 +24,11 @@ # SGML tables of wait events for inclusion in the documentation. # # When adding a new wait event, make sure it is placed in the appropriate -# ClassName section. +# ClassName section. If the wait event is backpatched from master to a version +# >= 17 then put it under a "Backpatch:" delimiter at the end of the related +# ClassName section (on the non master branches) or at its natural position on +# the master branch. +# Ensure that the backpatch regions are always empty on the master branch. # # WaitEventLWLock and WaitEventLock have their own C code for their wait event # enums and function names. Hence, for these, only the SGML documentation is @@ -61,6 +65,7 @@ WAL_SENDER_MAIN "Waiting in main loop of WAL sender process." WAL_SUMMARIZER_WAL "Waiting in WAL summarizer for more WAL to be generated." WAL_WRITER_MAIN "Waiting in main loop of WAL writer process." +Backpatch: # # Wait Events - Client @@ -82,6 +87,7 @@ WAIT_FOR_STANDBY_CONFIRMATION "Waiting for WAL to be received and flushed by the WAL_SENDER_WAIT_FOR_WAL "Waiting for WAL to be flushed in WAL sender process." WAL_SENDER_WRITE_DATA "Waiting for any activity when processing replies from WAL receiver in WAL sender process." +Backpatch: # # Wait Events - IPC @@ -149,6 +155,7 @@ WAL_RECEIVER_WAIT_START "Waiting for startup process to send initial data for st WAL_SUMMARY_READY "Waiting for a new WAL summary to be generated." XACT_GROUP_UPDATE "Waiting for the group leader to update transaction status at end of a parallel operation." +Backpatch: # # Wait Events - Timeout @@ -169,6 +176,7 @@ VACUUM_DELAY "Waiting in a cost-based vacuum delay point." VACUUM_TRUNCATE "Waiting to acquire an exclusive lock to truncate off any empty pages at the end of a table vacuumed." WAL_SUMMARIZER_ERROR "Waiting after a WAL summarizer error." +Backpatch: # # Wait Events - IO @@ -256,6 +264,7 @@ WAL_SYNC "Waiting for a WAL file to reach durable storage." WAL_SYNC_METHOD_ASSIGN "Waiting for data to reach durable storage while assigning a new WAL sync method." WAL_WRITE "Waiting for a write to a WAL file." +Backpatch: # # Wait Events - Buffer Pin @@ -265,6 +274,7 @@ Section: ClassName - WaitEventBufferPin BUFFER_PIN "Waiting to acquire an exclusive pin on a buffer." +Backpatch: # # Wait Events - Extension @@ -274,6 +284,8 @@ Section: ClassName - WaitEventExtension Extension "Waiting in an extension." +Backpatch: + # # Wait Events - LWLock # @@ -330,6 +342,8 @@ DSMRegistry "Waiting to read or update the dynamic shared memory registry." InjectionPoint "Waiting to read or update information related to injection points." SerialControl "Waiting to read or update shared <filename>pg_serial</filename> state." +# Don't create a Backpatch region here. + # # END OF PREDEFINED LWLOCKS (DO NOT CHANGE THIS LINE) # @@ -377,6 +391,7 @@ SerialSLRU "Waiting to access the serializable transaction conflict SLRU cache." SubtransSLRU "Waiting to access the sub-transaction SLRU cache." XactSLRU "Waiting to access the transaction status SLRU cache." +# Don't create a Backpatch region here. # # Wait Events - Lock @@ -399,3 +414,5 @@ object "Waiting to acquire a lock on a non-relation database object." userlock "Waiting to acquire a user lock." advisory "Waiting to acquire an advisory user lock." applytransaction "Waiting to acquire a lock on a remote transaction being applied by a logical replication subscriber." + +Backpatch: -- 2.34.1 --Xg/TgUq/K7vNmQT2-- ^ permalink raw reply [nested|flat] 21+ messages in thread
* [PATCH v3] Add "Backpatch" regions in wait_event_names.txt @ 2024-03-18 08:34 Bertrand Drouvot <[email protected]> 0 siblings, 0 replies; 21+ messages in thread From: Bertrand Drouvot @ 2024-03-18 08:34 UTC (permalink / raw) When backpatching, adding an event will renumber others, which can make an extension report the wrong event until recompiled. This is due to the fact that generate-wait_event_types.pl sorts events to position them. The "Backpatch" region added here ensures no ordering is done for the wait events found after this delimiter. --- .../activity/generate-wait_event_types.pl | 26 ++++++++++++++++++- .../utils/activity/wait_event_names.txt | 18 ++++++++++++- 2 files changed, 42 insertions(+), 2 deletions(-) 100.0% src/backend/utils/activity/ diff --git a/src/backend/utils/activity/generate-wait_event_types.pl b/src/backend/utils/activity/generate-wait_event_types.pl index f1adf0e8e7..d129d94889 100644 --- a/src/backend/utils/activity/generate-wait_event_types.pl +++ b/src/backend/utils/activity/generate-wait_event_types.pl @@ -38,7 +38,9 @@ die "Not possible to specify --docs and --code simultaneously" open my $wait_event_names, '<', $ARGV[0] or die; +my @backpatch_lines; my @lines; +my $backpatch = 0; my $section_name; my $note; my $note_name; @@ -59,10 +61,26 @@ while (<$wait_event_names>) { $section_name = $_; $section_name =~ s/^.*- //; + $backpatch = 0; next; } - push(@lines, $section_name . "\t" . $_); + # Are we dealing with backpatch wait events? + if (/^Backpatch:$/) + { + $backpatch = 1; + next; + } + + # Backpatch wait events won't be sorted during code generation + if ($gen_code && $backpatch) + { + push(@backpatch_lines, $section_name . "\t" . $_); + } + else + { + push(@lines, $section_name . "\t" . $_); + } } # Sort the lines based on the second column. @@ -70,6 +88,12 @@ while (<$wait_event_names>) my @lines_sorted = sort { uc((split(/\t/, $a))[1]) cmp uc((split(/\t/, $b))[1]) } @lines; +# If we are generating code then concat @lines_sorted and @backpatch_lines. +if ($gen_code) +{ + push(@lines_sorted, @backpatch_lines); +} + # Read the sorted lines and populate the hash table foreach my $line (@lines_sorted) { diff --git a/src/backend/utils/activity/wait_event_names.txt b/src/backend/utils/activity/wait_event_names.txt index c08e00d1d6..0c4788fe77 100644 --- a/src/backend/utils/activity/wait_event_names.txt +++ b/src/backend/utils/activity/wait_event_names.txt @@ -24,7 +24,10 @@ # SGML tables of wait events for inclusion in the documentation. # # When adding a new wait event, make sure it is placed in the appropriate -# ClassName section. +# ClassName section. Put it in its natural position in the master branch, and +# then put it in the "Backpatch:" region for any other branch (should the wait +# event be backpatched). +# Ensure that the backpatch regions are always empty on the master branch. # # WaitEventLWLock and WaitEventLock have their own C code for their wait event # enums and function names. Hence, for these, only the SGML documentation is @@ -61,6 +64,7 @@ WAL_SENDER_MAIN "Waiting in main loop of WAL sender process." WAL_SUMMARIZER_WAL "Waiting in WAL summarizer for more WAL to be generated." WAL_WRITER_MAIN "Waiting in main loop of WAL writer process." +Backpatch: # # Wait Events - Client @@ -82,6 +86,7 @@ WAIT_FOR_STANDBY_CONFIRMATION "Waiting for WAL to be received and flushed by the WAL_SENDER_WAIT_FOR_WAL "Waiting for WAL to be flushed in WAL sender process." WAL_SENDER_WRITE_DATA "Waiting for any activity when processing replies from WAL receiver in WAL sender process." +Backpatch: # # Wait Events - IPC @@ -149,6 +154,7 @@ WAL_RECEIVER_WAIT_START "Waiting for startup process to send initial data for st WAL_SUMMARY_READY "Waiting for a new WAL summary to be generated." XACT_GROUP_UPDATE "Waiting for the group leader to update transaction status at end of a parallel operation." +Backpatch: # # Wait Events - Timeout @@ -169,6 +175,7 @@ VACUUM_DELAY "Waiting in a cost-based vacuum delay point." VACUUM_TRUNCATE "Waiting to acquire an exclusive lock to truncate off any empty pages at the end of a table vacuumed." WAL_SUMMARIZER_ERROR "Waiting after a WAL summarizer error." +Backpatch: # # Wait Events - IO @@ -256,6 +263,7 @@ WAL_SYNC "Waiting for a WAL file to reach durable storage." WAL_SYNC_METHOD_ASSIGN "Waiting for data to reach durable storage while assigning a new WAL sync method." WAL_WRITE "Waiting for a write to a WAL file." +Backpatch: # # Wait Events - Buffer Pin @@ -265,6 +273,7 @@ Section: ClassName - WaitEventBufferPin BUFFER_PIN "Waiting to acquire an exclusive pin on a buffer." +Backpatch: # # Wait Events - Extension @@ -274,6 +283,8 @@ Section: ClassName - WaitEventExtension Extension "Waiting in an extension." +Backpatch: + # # Wait Events - LWLock # @@ -330,6 +341,8 @@ DSMRegistry "Waiting to read or update the dynamic shared memory registry." InjectionPoint "Waiting to read or update information related to injection points." SerialControl "Waiting to read or update shared <filename>pg_serial</filename> state." +# Don't create a Backpatch region here. + # # END OF PREDEFINED LWLOCKS (DO NOT CHANGE THIS LINE) # @@ -377,6 +390,7 @@ SerialSLRU "Waiting to access the serializable transaction conflict SLRU cache." SubtransSLRU "Waiting to access the sub-transaction SLRU cache." XactSLRU "Waiting to access the transaction status SLRU cache." +# Don't create a Backpatch region here. # # Wait Events - Lock @@ -399,3 +413,5 @@ object "Waiting to acquire a lock on a non-relation database object." userlock "Waiting to acquire a user lock." advisory "Waiting to acquire an advisory user lock." applytransaction "Waiting to acquire a lock on a remote transaction being applied by a logical replication subscriber." + +Backpatch: -- 2.34.1 --m1fyrkxSXqjY+FO1-- ^ permalink raw reply [nested|flat] 21+ messages in thread
* [PATCH v2] Add "Backpatch" regions in wait_event_names.txt @ 2024-03-18 08:34 Bertrand Drouvot <[email protected]> 0 siblings, 0 replies; 21+ messages in thread From: Bertrand Drouvot @ 2024-03-18 08:34 UTC (permalink / raw) When backpatching, adding an event will renumber others, which can make an extension report the wrong event until recompiled. This is due to the fact that generate-wait_event_types.pl sorts events to position them. The "Backpatch" region added here ensures no ordering is done for the wait events found after this delimiter. --- .../activity/generate-wait_event_types.pl | 26 ++++++++++++++++++- .../utils/activity/wait_event_names.txt | 19 +++++++++++++- 2 files changed, 43 insertions(+), 2 deletions(-) 100.0% src/backend/utils/activity/ diff --git a/src/backend/utils/activity/generate-wait_event_types.pl b/src/backend/utils/activity/generate-wait_event_types.pl index f1adf0e8e7..d129d94889 100644 --- a/src/backend/utils/activity/generate-wait_event_types.pl +++ b/src/backend/utils/activity/generate-wait_event_types.pl @@ -38,7 +38,9 @@ die "Not possible to specify --docs and --code simultaneously" open my $wait_event_names, '<', $ARGV[0] or die; +my @backpatch_lines; my @lines; +my $backpatch = 0; my $section_name; my $note; my $note_name; @@ -59,10 +61,26 @@ while (<$wait_event_names>) { $section_name = $_; $section_name =~ s/^.*- //; + $backpatch = 0; next; } - push(@lines, $section_name . "\t" . $_); + # Are we dealing with backpatch wait events? + if (/^Backpatch:$/) + { + $backpatch = 1; + next; + } + + # Backpatch wait events won't be sorted during code generation + if ($gen_code && $backpatch) + { + push(@backpatch_lines, $section_name . "\t" . $_); + } + else + { + push(@lines, $section_name . "\t" . $_); + } } # Sort the lines based on the second column. @@ -70,6 +88,12 @@ while (<$wait_event_names>) my @lines_sorted = sort { uc((split(/\t/, $a))[1]) cmp uc((split(/\t/, $b))[1]) } @lines; +# If we are generating code then concat @lines_sorted and @backpatch_lines. +if ($gen_code) +{ + push(@lines_sorted, @backpatch_lines); +} + # Read the sorted lines and populate the hash table foreach my $line (@lines_sorted) { diff --git a/src/backend/utils/activity/wait_event_names.txt b/src/backend/utils/activity/wait_event_names.txt index c08e00d1d6..b6303a0fdb 100644 --- a/src/backend/utils/activity/wait_event_names.txt +++ b/src/backend/utils/activity/wait_event_names.txt @@ -24,7 +24,11 @@ # SGML tables of wait events for inclusion in the documentation. # # When adding a new wait event, make sure it is placed in the appropriate -# ClassName section. +# ClassName section. If the wait event is backpatched from master to a version +# >= 17 then put it under a "Backpatch:" delimiter at the end of the related +# ClassName section (on the non master branches) or at its natural position on +# the master branch. +# Ensure that the backpatch regions are always empty on the master branch. # # WaitEventLWLock and WaitEventLock have their own C code for their wait event # enums and function names. Hence, for these, only the SGML documentation is @@ -61,6 +65,7 @@ WAL_SENDER_MAIN "Waiting in main loop of WAL sender process." WAL_SUMMARIZER_WAL "Waiting in WAL summarizer for more WAL to be generated." WAL_WRITER_MAIN "Waiting in main loop of WAL writer process." +Backpatch: # # Wait Events - Client @@ -82,6 +87,7 @@ WAIT_FOR_STANDBY_CONFIRMATION "Waiting for WAL to be received and flushed by the WAL_SENDER_WAIT_FOR_WAL "Waiting for WAL to be flushed in WAL sender process." WAL_SENDER_WRITE_DATA "Waiting for any activity when processing replies from WAL receiver in WAL sender process." +Backpatch: # # Wait Events - IPC @@ -149,6 +155,7 @@ WAL_RECEIVER_WAIT_START "Waiting for startup process to send initial data for st WAL_SUMMARY_READY "Waiting for a new WAL summary to be generated." XACT_GROUP_UPDATE "Waiting for the group leader to update transaction status at end of a parallel operation." +Backpatch: # # Wait Events - Timeout @@ -169,6 +176,7 @@ VACUUM_DELAY "Waiting in a cost-based vacuum delay point." VACUUM_TRUNCATE "Waiting to acquire an exclusive lock to truncate off any empty pages at the end of a table vacuumed." WAL_SUMMARIZER_ERROR "Waiting after a WAL summarizer error." +Backpatch: # # Wait Events - IO @@ -256,6 +264,7 @@ WAL_SYNC "Waiting for a WAL file to reach durable storage." WAL_SYNC_METHOD_ASSIGN "Waiting for data to reach durable storage while assigning a new WAL sync method." WAL_WRITE "Waiting for a write to a WAL file." +Backpatch: # # Wait Events - Buffer Pin @@ -265,6 +274,7 @@ Section: ClassName - WaitEventBufferPin BUFFER_PIN "Waiting to acquire an exclusive pin on a buffer." +Backpatch: # # Wait Events - Extension @@ -274,6 +284,8 @@ Section: ClassName - WaitEventExtension Extension "Waiting in an extension." +Backpatch: + # # Wait Events - LWLock # @@ -330,6 +342,8 @@ DSMRegistry "Waiting to read or update the dynamic shared memory registry." InjectionPoint "Waiting to read or update information related to injection points." SerialControl "Waiting to read or update shared <filename>pg_serial</filename> state." +# Don't create a Backpatch region here. + # # END OF PREDEFINED LWLOCKS (DO NOT CHANGE THIS LINE) # @@ -377,6 +391,7 @@ SerialSLRU "Waiting to access the serializable transaction conflict SLRU cache." SubtransSLRU "Waiting to access the sub-transaction SLRU cache." XactSLRU "Waiting to access the transaction status SLRU cache." +# Don't create a Backpatch region here. # # Wait Events - Lock @@ -399,3 +414,5 @@ object "Waiting to acquire a lock on a non-relation database object." userlock "Waiting to acquire a user lock." advisory "Waiting to acquire an advisory user lock." applytransaction "Waiting to acquire a lock on a remote transaction being applied by a logical replication subscriber." + +Backpatch: -- 2.34.1 --Xg/TgUq/K7vNmQT2-- ^ permalink raw reply [nested|flat] 21+ messages in thread
* [PATCH v3] Add "Backpatch" regions in wait_event_names.txt @ 2024-03-18 08:34 Bertrand Drouvot <[email protected]> 0 siblings, 0 replies; 21+ messages in thread From: Bertrand Drouvot @ 2024-03-18 08:34 UTC (permalink / raw) When backpatching, adding an event will renumber others, which can make an extension report the wrong event until recompiled. This is due to the fact that generate-wait_event_types.pl sorts events to position them. The "Backpatch" region added here ensures no ordering is done for the wait events found after this delimiter. --- .../activity/generate-wait_event_types.pl | 26 ++++++++++++++++++- .../utils/activity/wait_event_names.txt | 18 ++++++++++++- 2 files changed, 42 insertions(+), 2 deletions(-) 100.0% src/backend/utils/activity/ diff --git a/src/backend/utils/activity/generate-wait_event_types.pl b/src/backend/utils/activity/generate-wait_event_types.pl index f1adf0e8e7..d129d94889 100644 --- a/src/backend/utils/activity/generate-wait_event_types.pl +++ b/src/backend/utils/activity/generate-wait_event_types.pl @@ -38,7 +38,9 @@ die "Not possible to specify --docs and --code simultaneously" open my $wait_event_names, '<', $ARGV[0] or die; +my @backpatch_lines; my @lines; +my $backpatch = 0; my $section_name; my $note; my $note_name; @@ -59,10 +61,26 @@ while (<$wait_event_names>) { $section_name = $_; $section_name =~ s/^.*- //; + $backpatch = 0; next; } - push(@lines, $section_name . "\t" . $_); + # Are we dealing with backpatch wait events? + if (/^Backpatch:$/) + { + $backpatch = 1; + next; + } + + # Backpatch wait events won't be sorted during code generation + if ($gen_code && $backpatch) + { + push(@backpatch_lines, $section_name . "\t" . $_); + } + else + { + push(@lines, $section_name . "\t" . $_); + } } # Sort the lines based on the second column. @@ -70,6 +88,12 @@ while (<$wait_event_names>) my @lines_sorted = sort { uc((split(/\t/, $a))[1]) cmp uc((split(/\t/, $b))[1]) } @lines; +# If we are generating code then concat @lines_sorted and @backpatch_lines. +if ($gen_code) +{ + push(@lines_sorted, @backpatch_lines); +} + # Read the sorted lines and populate the hash table foreach my $line (@lines_sorted) { diff --git a/src/backend/utils/activity/wait_event_names.txt b/src/backend/utils/activity/wait_event_names.txt index c08e00d1d6..0c4788fe77 100644 --- a/src/backend/utils/activity/wait_event_names.txt +++ b/src/backend/utils/activity/wait_event_names.txt @@ -24,7 +24,10 @@ # SGML tables of wait events for inclusion in the documentation. # # When adding a new wait event, make sure it is placed in the appropriate -# ClassName section. +# ClassName section. Put it in its natural position in the master branch, and +# then put it in the "Backpatch:" region for any other branch (should the wait +# event be backpatched). +# Ensure that the backpatch regions are always empty on the master branch. # # WaitEventLWLock and WaitEventLock have their own C code for their wait event # enums and function names. Hence, for these, only the SGML documentation is @@ -61,6 +64,7 @@ WAL_SENDER_MAIN "Waiting in main loop of WAL sender process." WAL_SUMMARIZER_WAL "Waiting in WAL summarizer for more WAL to be generated." WAL_WRITER_MAIN "Waiting in main loop of WAL writer process." +Backpatch: # # Wait Events - Client @@ -82,6 +86,7 @@ WAIT_FOR_STANDBY_CONFIRMATION "Waiting for WAL to be received and flushed by the WAL_SENDER_WAIT_FOR_WAL "Waiting for WAL to be flushed in WAL sender process." WAL_SENDER_WRITE_DATA "Waiting for any activity when processing replies from WAL receiver in WAL sender process." +Backpatch: # # Wait Events - IPC @@ -149,6 +154,7 @@ WAL_RECEIVER_WAIT_START "Waiting for startup process to send initial data for st WAL_SUMMARY_READY "Waiting for a new WAL summary to be generated." XACT_GROUP_UPDATE "Waiting for the group leader to update transaction status at end of a parallel operation." +Backpatch: # # Wait Events - Timeout @@ -169,6 +175,7 @@ VACUUM_DELAY "Waiting in a cost-based vacuum delay point." VACUUM_TRUNCATE "Waiting to acquire an exclusive lock to truncate off any empty pages at the end of a table vacuumed." WAL_SUMMARIZER_ERROR "Waiting after a WAL summarizer error." +Backpatch: # # Wait Events - IO @@ -256,6 +263,7 @@ WAL_SYNC "Waiting for a WAL file to reach durable storage." WAL_SYNC_METHOD_ASSIGN "Waiting for data to reach durable storage while assigning a new WAL sync method." WAL_WRITE "Waiting for a write to a WAL file." +Backpatch: # # Wait Events - Buffer Pin @@ -265,6 +273,7 @@ Section: ClassName - WaitEventBufferPin BUFFER_PIN "Waiting to acquire an exclusive pin on a buffer." +Backpatch: # # Wait Events - Extension @@ -274,6 +283,8 @@ Section: ClassName - WaitEventExtension Extension "Waiting in an extension." +Backpatch: + # # Wait Events - LWLock # @@ -330,6 +341,8 @@ DSMRegistry "Waiting to read or update the dynamic shared memory registry." InjectionPoint "Waiting to read or update information related to injection points." SerialControl "Waiting to read or update shared <filename>pg_serial</filename> state." +# Don't create a Backpatch region here. + # # END OF PREDEFINED LWLOCKS (DO NOT CHANGE THIS LINE) # @@ -377,6 +390,7 @@ SerialSLRU "Waiting to access the serializable transaction conflict SLRU cache." SubtransSLRU "Waiting to access the sub-transaction SLRU cache." XactSLRU "Waiting to access the transaction status SLRU cache." +# Don't create a Backpatch region here. # # Wait Events - Lock @@ -399,3 +413,5 @@ object "Waiting to acquire a lock on a non-relation database object." userlock "Waiting to acquire a user lock." advisory "Waiting to acquire an advisory user lock." applytransaction "Waiting to acquire a lock on a remote transaction being applied by a logical replication subscriber." + +Backpatch: -- 2.34.1 --m1fyrkxSXqjY+FO1-- ^ permalink raw reply [nested|flat] 21+ messages in thread
* Re: EXPLAIN IndexOnlyScan shows disabled when enable_indexonlyscan=on @ 2024-10-22 01:32 David Rowley <[email protected]> 0 siblings, 1 reply; 21+ messages in thread From: David Rowley @ 2024-10-22 01:32 UTC (permalink / raw) To: Melanie Plageman <[email protected]>; +Cc: pgsql-hackers; Robert Haas <[email protected]> On Tue, 22 Oct 2024 at 13:45, Melanie Plageman <[email protected]> wrote: > I was surprised today when I saw that with > enable_indexscan=off > enable_indexonlyscan=on > EXPLAIN prints that the index only scan is disabled: > > QUERY PLAN > ----------------------------------------------- > Index Only Scan using history_pkey on history > Disabled: true There's nothing new about Index Only Scans being disabled by enable_indexscan. Index Only Scan is chosen with your test case as all possible Paths are disabled and IOS is the cheapest of all Paths. The PG17 results for your test case are: QUERY PLAN --------------------------------------------------------------------------------------------------------- Index Only Scan using history_pkey on history (cost=10000000000.29..10000000527.78 rows=19966 width=4) (1 row) (note the 1e10 disable_cost has been applied to the Index Only Scan costs) Robert did propose to change this behaviour while he was working on the disabled_nodes changes. I did push back on the proposed change [1]. If you feel strongly that what we have is wrong, then maybe it's worth opening the discussion about that again. David [1] https://www.postgresql.org/message-id/CAApHDvoUUKi0JNv8jtZPfc_JkLs7FqymC5-DDUFNKnm4MMmPuQ%40mail.gma... ^ permalink raw reply [nested|flat] 21+ messages in thread
* EXPLAIN IndexOnlyScan shows disabled when enable_indexonlyscan=on @ 2024-10-22 01:46 David G. Johnston <[email protected]> parent: David Rowley <[email protected]> 0 siblings, 1 reply; 21+ messages in thread From: David G. Johnston @ 2024-10-22 01:46 UTC (permalink / raw) To: David Rowley <[email protected]>; +Cc: Melanie Plageman <[email protected]>; pgsql-hackers; Robert Haas <[email protected]> On Monday, October 21, 2024, David Rowley <[email protected]> wrote: > On Tue, 22 Oct 2024 at 13:45, Melanie Plageman > <[email protected]> wrote: > > I was surprised today when I saw that with > > enable_indexscan=off > > enable_indexonlyscan=on > > Robert did propose to change this behaviour while he was working on > the disabled_nodes changes. I did push back on the proposed change > [1]. If you feel strongly that what we have is wrong, then maybe it's > worth opening the discussion about that again. > We should probably at least improve the documentation in 19.17.1; this interaction is apparently not self-evident. enable_indexscan Enable or disable the planner’s use of both index-scan and index-only-scans plan types. enabled_indexonlyscan Set to off to disable index-only-scan plan type while leaving index-scan plan types enabled. This setting has no effect if enable_indexscan is set to off. David J. ^ permalink raw reply [nested|flat] 21+ messages in thread
* Re: EXPLAIN IndexOnlyScan shows disabled when enable_indexonlyscan=on @ 2024-10-22 02:20 David Rowley <[email protected]> parent: David G. Johnston <[email protected]> 0 siblings, 2 replies; 21+ messages in thread From: David Rowley @ 2024-10-22 02:20 UTC (permalink / raw) To: David G. Johnston <[email protected]>; +Cc: Melanie Plageman <[email protected]>; pgsql-hackers; Robert Haas <[email protected]> On Tue, 22 Oct 2024 at 14:46, David G. Johnston <[email protected]> wrote: > We should probably at least improve the documentation in 19.17.1; this interaction is apparently not self-evident. > > enable_indexscan > > Enable or disable the planner’s use of both index-scan and index-only-scans plan types. > > enabled_indexonlyscan > > Set to off to disable index-only-scan plan type while leaving index-scan plan types enabled. This setting has no effect if enable_indexscan is set to off. Yeah, I agree. The documentation could better reflect the current behaviour. Do you want to submit that in patch form? David ^ permalink raw reply [nested|flat] 21+ messages in thread
* Re: EXPLAIN IndexOnlyScan shows disabled when enable_indexonlyscan=on @ 2024-10-22 02:40 David G. Johnston <[email protected]> parent: David Rowley <[email protected]> 1 sibling, 0 replies; 21+ messages in thread From: David G. Johnston @ 2024-10-22 02:40 UTC (permalink / raw) To: David Rowley <[email protected]>; +Cc: Melanie Plageman <[email protected]>; pgsql-hackers; Robert Haas <[email protected]> On Monday, October 21, 2024, David Rowley <[email protected]> wrote: > On Tue, 22 Oct 2024 at 14:46, David G. Johnston > <[email protected]> wrote: > > We should probably at least improve the documentation in 19.17.1; this > interaction is apparently not self-evident. > > > > enable_indexscan > > > > Enable or disable the planner’s use of both index-scan and > index-only-scans plan types. > > > > enabled_indexonlyscan > > > > Set to off to disable index-only-scan plan type while leaving index-scan > plan types enabled. This setting has no effect if enable_indexscan is set > to off. > > Yeah, I agree. The documentation could better reflect the current > behaviour. > > Do you want to submit that in patch form? > Will do tomorrow. David J. ^ permalink raw reply [nested|flat] 21+ messages in thread
* Re: EXPLAIN IndexOnlyScan shows disabled when enable_indexonlyscan=on @ 2024-10-23 00:50 David G. Johnston <[email protected]> parent: David Rowley <[email protected]> 1 sibling, 1 reply; 21+ messages in thread From: David G. Johnston @ 2024-10-23 00:50 UTC (permalink / raw) To: David Rowley <[email protected]>; +Cc: Melanie Plageman <[email protected]>; pgsql-hackers; Robert Haas <[email protected]> On Mon, Oct 21, 2024 at 7:20 PM David Rowley <[email protected]> wrote: > On Tue, 22 Oct 2024 at 14:46, David G. Johnston > <[email protected]> wrote: > > We should probably at least improve the documentation in 19.17.1; this > interaction is apparently not self-evident. > > Yeah, I agree. The documentation could better reflect the current > behaviour. > > Do you want to submit that in patch form? > > Went with a slightly different wording that seems to flow better with the xrefs I added between the two options. David J. Attachments: [text/x-patch] v1-0001-doc-Cross-reference-enable_indexscan-and-enable_inde.patch (2.2K, ../../CAKFQuwbNOj4f6ar1+jkBFGhK+t6fNwzM0ygLh7GBFSxVGSO8TQ@mail.gmail.com/3-v1-0001-doc-Cross-reference-enable_indexscan-and-enable_inde.patch) download | inline diff: From 8b9be4096352088ea22f114e68041fd09ee6e28c Mon Sep 17 00:00:00 2001 From: "David G. Johnston" <[email protected]> Date: Tue, 22 Oct 2024 17:25:27 -0700 Subject: [PATCH] doc: Cross reference enable_indexscan and enable_indexonlyscan Document that enable_indexscan controls the inclusion of all (normal and index-only) index scan plan node types. Note that index-only scans can be independently disabled. Note the implication of this in enable_indexonlyscan, that a setting of "on" is ignored when all index scans types are disabled. Left unwritten is the absence of a symmetric option to exclude normal index scans while allowing index-only scans. --- doc/src/sgml/config.sgml | 11 +++++++---- 1 file changed, 7 insertions(+), 4 deletions(-) diff --git a/doc/src/sgml/config.sgml b/doc/src/sgml/config.sgml index 934ef5e469..04cbe7ac34 100644 --- a/doc/src/sgml/config.sgml +++ b/doc/src/sgml/config.sgml @@ -5415,8 +5415,10 @@ ANY <replaceable class="parameter">num_sync</replaceable> ( <replaceable class=" </term> <listitem> <para> - Enables or disables the query planner's use of index-scan plan - types. The default is <literal>on</literal>. + Enables or disables the query planner's use of all index-scan related plan + types. The default is <literal>on</literal>. The index-only-scan plan types + can be independently disabled by setting <xref linkend="guc-enable-indexonlyscan"/> + to <literal>off</literal>. </para> </listitem> </varlistentry> @@ -5429,9 +5431,10 @@ ANY <replaceable class="parameter">num_sync</replaceable> ( <replaceable class=" </term> <listitem> <para> - Enables or disables the query planner's use of index-only-scan plan + Set to <literal>off</literal> to disable the query planner's use of index-only-scan plan types (see <xref linkend="indexes-index-only-scans"/>). - The default is <literal>on</literal>. + The default is <literal>on</literal>. However, this setting has no effect if + <xref linkend="guc-enable-indexscan"/> is set to <literal>off</literal>. </para> </listitem> </varlistentry> -- 2.34.1 ^ permalink raw reply [nested|flat] 21+ messages in thread
* Re: EXPLAIN IndexOnlyScan shows disabled when enable_indexonlyscan=on @ 2024-10-28 22:54 David Rowley <[email protected]> parent: David G. Johnston <[email protected]> 0 siblings, 2 replies; 21+ messages in thread From: David Rowley @ 2024-10-28 22:54 UTC (permalink / raw) To: David G. Johnston <[email protected]>; +Cc: Melanie Plageman <[email protected]>; pgsql-hackers; Robert Haas <[email protected]> On Wed, 23 Oct 2024 at 13:51, David G. Johnston <[email protected]> wrote: > Went with a slightly different wording that seems to flow better with the xrefs I added between the two options. - Enables or disables the query planner's use of index-scan plan - types. The default is <literal>on</literal>. + Enables or disables the query planner's use of all index-scan related plan I'm concerned about the wording "all index-scan related". It's not that clear if that would include Bitmap Index Scans or not. I think it's better to explicitly mention index-only-scans to make it clear which nodes are affected. + types. The default is <literal>on</literal>. The index-only-scan plan types + can be independently disabled by setting <xref linkend="guc-enable-indexonlyscan"/> + to <literal>off</literal>. I wondered if it's better to reference the enable_indexonlyscan GUC here rather than document what enable_indexonlyscan does from the enable_indexscan docs. Maybe just a "Also see enable_indexonlyscans." could be added? - The default is <literal>on</literal>. + The default is <literal>on</literal>. However, this setting has no effect if + <xref linkend="guc-enable-indexscan"/> is set to <literal>off</literal>. Could we just add "The <xref linkend="guc-enable-indexscan"/> setting must also be enabled to have the query planner consider index-only-scans"? I've attached that in patch form. David Attachments: [text/html] runtime-config-query.html (47.8K, ../../CAApHDvrR=0ExMOEQvnwWfck2NSk=_pktwNDvybYS-ziB74kT1w@mail.gmail.com/2-runtime-config-query.html) download | inline: <?xml version="1.0" encoding="UTF-8" standalone="no"?> <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd"><html xmlns="http://www.w3.org/1999/xhtml"><head><meta http-equiv="Content-Type" content="text/html; charset=UTF-8" /><title>19.7. Query Planning</title><link rel="stylesheet" type="text/css" href="https://www.postgresql.org/media/css/docs-complete.css" /><link rev="made" href="[email protected]" /><meta name="generator" content="DocBook XSL Stylesheets Vsnapshot" /><link rel="prev" href="runtime-config-replication.html" title="19.6. Replication" /><link rel="next" href="runtime-config-logging.html" title="19.8. Error Reporting and Logging" /></head><body id="docContent" class="container-fluid col-10"><div class="navheader"><table width="100%" summary="Navigation header"><tr><th colspan="5" align="center">19.7. Query Planning</th></tr><tr><td width="10%" align="left"><a accesskey="p" href="runtime-config-replication.html" title="19.6. Replication">Prev</a> </td><td width="10%" align="left"><a accesskey="u" href="runtime-config.html" title="Chapter 19. Server Configuration">Up</a></td><th width="60%" align="center">Chapter 19. Server Configuration</th><td width="10%" align="right"><a accesskey="h" href="index.html" title="PostgreSQL 18devel Documentation">Home</a></td><td width="10%" align="right"> <a accesskey="n" href="runtime-config-logging.html" title="19.8. Error Reporting and Logging">Next</a></td></tr></table><hr /></div><div class="sect1" id="RUNTIME-CONFIG-QUERY"><div class="titlepage"><div><div><h2 class="title" style="clear: both">19.7. Query Planning <a href="#RUNTIME-CONFIG-QUERY" class="id_link">#</a></h2></div></div></div><div class="toc"><dl class="toc"><dt><span class="sect2"><a href="runtime-config-query.html#RUNTIME-CONFIG-QUERY-ENABLE">19.7.1. Planner Method Configuration</a></span></dt><dt><span class="sect2"><a href="runtime-config-query.html#RUNTIME-CONFIG-QUERY-CONSTANTS">19.7.2. Planner Cost Constants</a></span></dt><dt><span class="sect2"><a href="runtime-config-query.html#RUNTIME-CONFIG-QUERY-GEQO">19.7.3. Genetic Query Optimizer</a></span></dt><dt><span class="sect2"><a href="runtime-config-query.html#RUNTIME-CONFIG-QUERY-OTHER">19.7.4. Other Planner Options</a></span></dt></dl></div><div class="sect2" id="RUNTIME-CONFIG-QUERY-ENABLE"><div class="titlepage"><div><div><h3 class="title">19.7.1. Planner Method Configuration <a href="#RUNTIME-CONFIG-QUERY-ENABLE" class="id_link">#</a></h3></div></div></div><p> These configuration parameters provide a crude method of influencing the query plans chosen by the query optimizer. If the default plan chosen by the optimizer for a particular query is not optimal, a <span class="emphasis"><em>temporary</em></span> solution is to use one of these configuration parameters to force the optimizer to choose a different plan. Better ways to improve the quality of the plans chosen by the optimizer include adjusting the planner cost constants (see <a class="xref" href="runtime-config-query.html#RUNTIME-CONFIG-QUERY-CONSTANTS" title="19.7.2. Planner Cost Constants">Section 19.7.2</a>), running <a class="link" href="sql-analyze.html" title="ANALYZE"><code class="command">ANALYZE</code></a> manually, increasing the value of the <a class="xref" href="runtime-config-query.html#GUC-DEFAULT-STATISTICS-TARGET">default_statistics_target</a> configuration parameter, and increasing the amount of statistics collected for specific columns using <code class="command">ALTER TABLE SET STATISTICS</code>. </p><div class="variablelist"><dl class="variablelist"><dt id="GUC-ENABLE-ASYNC-APPEND"><span class="term"><code class="varname">enable_async_append</code> (<code class="type">boolean</code>) <a id="id-1.6.6.10.2.3.1.1.3" class="indexterm"></a> </span> <a href="#GUC-ENABLE-ASYNC-APPEND" class="id_link">#</a></dt><dd><p> Enables or disables the query planner's use of async-aware append plan types. The default is <code class="literal">on</code>. </p></dd><dt id="GUC-ENABLE-BITMAPSCAN"><span class="term"><code class="varname">enable_bitmapscan</code> (<code class="type">boolean</code>) <a id="id-1.6.6.10.2.3.2.1.3" class="indexterm"></a> <a id="id-1.6.6.10.2.3.2.1.4" class="indexterm"></a> </span> <a href="#GUC-ENABLE-BITMAPSCAN" class="id_link">#</a></dt><dd><p> Enables or disables the query planner's use of bitmap-scan plan types. The default is <code class="literal">on</code>. </p></dd><dt id="GUC-ENABLE-GATHERMERGE"><span class="term"><code class="varname">enable_gathermerge</code> (<code class="type">boolean</code>) <a id="id-1.6.6.10.2.3.3.1.3" class="indexterm"></a> </span> <a href="#GUC-ENABLE-GATHERMERGE" class="id_link">#</a></dt><dd><p> Enables or disables the query planner's use of gather merge plan types. The default is <code class="literal">on</code>. </p></dd><dt id="GUC-ENABLE-GROUPBY-REORDERING"><span class="term"><code class="varname">enable_group_by_reordering</code> (<code class="type">boolean</code>) <a id="id-1.6.6.10.2.3.4.1.3" class="indexterm"></a> </span> <a href="#GUC-ENABLE-GROUPBY-REORDERING" class="id_link">#</a></dt><dd><p> Controls if the query planner will produce a plan which will provide <code class="literal">GROUP BY</code> keys sorted in the order of keys of a child node of the plan, such as an index scan. When disabled, the query planner will produce a plan with <code class="literal">GROUP BY</code> keys only sorted to match the <code class="literal">ORDER BY</code> clause, if any. When enabled, the planner will try to produce a more efficient plan. The default value is <code class="literal">on</code>. </p></dd><dt id="GUC-ENABLE-HASHAGG"><span class="term"><code class="varname">enable_hashagg</code> (<code class="type">boolean</code>) <a id="id-1.6.6.10.2.3.5.1.3" class="indexterm"></a> </span> <a href="#GUC-ENABLE-HASHAGG" class="id_link">#</a></dt><dd><p> Enables or disables the query planner's use of hashed aggregation plan types. The default is <code class="literal">on</code>. </p></dd><dt id="GUC-ENABLE-HASHJOIN"><span class="term"><code class="varname">enable_hashjoin</code> (<code class="type">boolean</code>) <a id="id-1.6.6.10.2.3.6.1.3" class="indexterm"></a> </span> <a href="#GUC-ENABLE-HASHJOIN" class="id_link">#</a></dt><dd><p> Enables or disables the query planner's use of hash-join plan types. The default is <code class="literal">on</code>. </p></dd><dt id="GUC-ENABLE-INCREMENTAL-SORT"><span class="term"><code class="varname">enable_incremental_sort</code> (<code class="type">boolean</code>) <a id="id-1.6.6.10.2.3.7.1.3" class="indexterm"></a> </span> <a href="#GUC-ENABLE-INCREMENTAL-SORT" class="id_link">#</a></dt><dd><p> Enables or disables the query planner's use of incremental sort steps. The default is <code class="literal">on</code>. </p></dd><dt id="GUC-ENABLE-INDEXSCAN"><span class="term"><code class="varname">enable_indexscan</code> (<code class="type">boolean</code>) <a id="id-1.6.6.10.2.3.8.1.3" class="indexterm"></a> <a id="id-1.6.6.10.2.3.8.1.4" class="indexterm"></a> </span> <a href="#GUC-ENABLE-INDEXSCAN" class="id_link">#</a></dt><dd><p> Enables or disables the query planner's use of index-scan and index-only-scan plan types. The default is <code class="literal">on</code>. Also see <a class="xref" href="runtime-config-query.html#GUC-ENABLE-INDEXONLYSCAN">enable_indexonlyscan</a>. </p></dd><dt id="GUC-ENABLE-INDEXONLYSCAN"><span class="term"><code class="varname">enable_indexonlyscan</code> (<code class="type">boolean</code>) <a id="id-1.6.6.10.2.3.9.1.3" class="indexterm"></a> </span> <a href="#GUC-ENABLE-INDEXONLYSCAN" class="id_link">#</a></dt><dd><p> Enables or disables the query planner's use of index-only-scan plan types (see <a class="xref" href="indexes-index-only-scans.html" title="11.9. Index-Only Scans and Covering Indexes">Section 11.9</a>). The default is <code class="literal">on</code>. The <a class="xref" href="runtime-config-query.html#GUC-ENABLE-INDEXSCAN">enable_indexscan</a> setting must also be enabled to have the query planner consider index-only-scans. </p></dd><dt id="GUC-ENABLE-MATERIAL"><span class="term"><code class="varname">enable_material</code> (<code class="type">boolean</code>) <a id="id-1.6.6.10.2.3.10.1.3" class="indexterm"></a> </span> <a href="#GUC-ENABLE-MATERIAL" class="id_link">#</a></dt><dd><p> Enables or disables the query planner's use of materialization. It is impossible to suppress materialization entirely, but turning this variable off prevents the planner from inserting materialize nodes except in cases where it is required for correctness. The default is <code class="literal">on</code>. </p></dd><dt id="GUC-ENABLE-MEMOIZE"><span class="term"><code class="varname">enable_memoize</code> (<code class="type">boolean</code>) <a id="id-1.6.6.10.2.3.11.1.3" class="indexterm"></a> </span> <a href="#GUC-ENABLE-MEMOIZE" class="id_link">#</a></dt><dd><p> Enables or disables the query planner's use of memoize plans for caching results from parameterized scans inside nested-loop joins. This plan type allows scans to the underlying plans to be skipped when the results for the current parameters are already in the cache. Less commonly looked up results may be evicted from the cache when more space is required for new entries. The default is <code class="literal">on</code>. </p></dd><dt id="GUC-ENABLE-MERGEJOIN"><span class="term"><code class="varname">enable_mergejoin</code> (<code class="type">boolean</code>) <a id="id-1.6.6.10.2.3.12.1.3" class="indexterm"></a> </span> <a href="#GUC-ENABLE-MERGEJOIN" class="id_link">#</a></dt><dd><p> Enables or disables the query planner's use of merge-join plan types. The default is <code class="literal">on</code>. </p></dd><dt id="GUC-ENABLE-NESTLOOP"><span class="term"><code class="varname">enable_nestloop</code> (<code class="type">boolean</code>) <a id="id-1.6.6.10.2.3.13.1.3" class="indexterm"></a> </span> <a href="#GUC-ENABLE-NESTLOOP" class="id_link">#</a></dt><dd><p> Enables or disables the query planner's use of nested-loop join plans. It is impossible to suppress nested-loop joins entirely, but turning this variable off discourages the planner from using one if there are other methods available. The default is <code class="literal">on</code>. </p></dd><dt id="GUC-ENABLE-PARALLEL-APPEND"><span class="term"><code class="varname">enable_parallel_append</code> (<code class="type">boolean</code>) <a id="id-1.6.6.10.2.3.14.1.3" class="indexterm"></a> </span> <a href="#GUC-ENABLE-PARALLEL-APPEND" class="id_link">#</a></dt><dd><p> Enables or disables the query planner's use of parallel-aware append plan types. The default is <code class="literal">on</code>. </p></dd><dt id="GUC-ENABLE-PARALLEL-HASH"><span class="term"><code class="varname">enable_parallel_hash</code> (<code class="type">boolean</code>) <a id="id-1.6.6.10.2.3.15.1.3" class="indexterm"></a> </span> <a href="#GUC-ENABLE-PARALLEL-HASH" class="id_link">#</a></dt><dd><p> Enables or disables the query planner's use of hash-join plan types with parallel hash. Has no effect if hash-join plans are not also enabled. The default is <code class="literal">on</code>. </p></dd><dt id="GUC-ENABLE-PARTITION-PRUNING"><span class="term"><code class="varname">enable_partition_pruning</code> (<code class="type">boolean</code>) <a id="id-1.6.6.10.2.3.16.1.3" class="indexterm"></a> </span> <a href="#GUC-ENABLE-PARTITION-PRUNING" class="id_link">#</a></dt><dd><p> Enables or disables the query planner's ability to eliminate a partitioned table's partitions from query plans. This also controls the planner's ability to generate query plans which allow the query executor to remove (ignore) partitions during query execution. The default is <code class="literal">on</code>. See <a class="xref" href="ddl-partitioning.html#DDL-PARTITION-PRUNING" title="5.12.4. Partition Pruning">Section 5.12.4</a> for details. </p></dd><dt id="GUC-ENABLE-PARTITIONWISE-JOIN"><span class="term"><code class="varname">enable_partitionwise_join</code> (<code class="type">boolean</code>) <a id="id-1.6.6.10.2.3.17.1.3" class="indexterm"></a> </span> <a href="#GUC-ENABLE-PARTITIONWISE-JOIN" class="id_link">#</a></dt><dd><p> Enables or disables the query planner's use of partitionwise join, which allows a join between partitioned tables to be performed by joining the matching partitions. Partitionwise join currently applies only when the join conditions include all the partition keys, which must be of the same data type and have one-to-one matching sets of child partitions. With this setting enabled, the number of nodes whose memory usage is restricted by <code class="varname">work_mem</code> appearing in the final plan can increase linearly according to the number of partitions being scanned. This can result in a large increase in overall memory consumption during the execution of the query. Query planning also becomes significantly more expensive in terms of memory and CPU. The default value is <code class="literal">off</code>. </p></dd><dt id="GUC-ENABLE-PARTITIONWISE-AGGREGATE"><span class="term"><code class="varname">enable_partitionwise_aggregate</code> (<code class="type">boolean</code>) <a id="id-1.6.6.10.2.3.18.1.3" class="indexterm"></a> </span> <a href="#GUC-ENABLE-PARTITIONWISE-AGGREGATE" class="id_link">#</a></dt><dd><p> Enables or disables the query planner's use of partitionwise grouping or aggregation, which allows grouping or aggregation on partitioned tables to be performed separately for each partition. If the <code class="literal">GROUP BY</code> clause does not include the partition keys, only partial aggregation can be performed on a per-partition basis, and finalization must be performed later. With this setting enabled, the number of nodes whose memory usage is restricted by <code class="varname">work_mem</code> appearing in the final plan can increase linearly according to the number of partitions being scanned. This can result in a large increase in overall memory consumption during the execution of the query. Query planning also becomes significantly more expensive in terms of memory and CPU. The default value is <code class="literal">off</code>. </p></dd><dt id="GUC-ENABLE-PRESORTED-AGGREGATE"><span class="term"><code class="varname">enable_presorted_aggregate</code> (<code class="type">boolean</code>) <a id="id-1.6.6.10.2.3.19.1.3" class="indexterm"></a> </span> <a href="#GUC-ENABLE-PRESORTED-AGGREGATE" class="id_link">#</a></dt><dd><p> Controls if the query planner will produce a plan which will provide rows which are presorted in the order required for the query's <code class="literal">ORDER BY</code> / <code class="literal">DISTINCT</code> aggregate functions. When disabled, the query planner will produce a plan which will always require the executor to perform a sort before performing aggregation of each aggregate function containing an <code class="literal">ORDER BY</code> or <code class="literal">DISTINCT</code> clause. When enabled, the planner will try to produce a more efficient plan which provides input to the aggregate functions which is presorted in the order they require for aggregation. The default value is <code class="literal">on</code>. </p></dd><dt id="GUC-ENABLE-SEQSCAN"><span class="term"><code class="varname">enable_seqscan</code> (<code class="type">boolean</code>) <a id="id-1.6.6.10.2.3.20.1.3" class="indexterm"></a> <a id="id-1.6.6.10.2.3.20.1.4" class="indexterm"></a> </span> <a href="#GUC-ENABLE-SEQSCAN" class="id_link">#</a></dt><dd><p> Enables or disables the query planner's use of sequential scan plan types. It is impossible to suppress sequential scans entirely, but turning this variable off discourages the planner from using one if there are other methods available. The default is <code class="literal">on</code>. </p></dd><dt id="GUC-ENABLE-SORT"><span class="term"><code class="varname">enable_sort</code> (<code class="type">boolean</code>) <a id="id-1.6.6.10.2.3.21.1.3" class="indexterm"></a> </span> <a href="#GUC-ENABLE-SORT" class="id_link">#</a></dt><dd><p> Enables or disables the query planner's use of explicit sort steps. It is impossible to suppress explicit sorts entirely, but turning this variable off discourages the planner from using one if there are other methods available. The default is <code class="literal">on</code>. </p></dd><dt id="GUC-ENABLE-TIDSCAN"><span class="term"><code class="varname">enable_tidscan</code> (<code class="type">boolean</code>) <a id="id-1.6.6.10.2.3.22.1.3" class="indexterm"></a> </span> <a href="#GUC-ENABLE-TIDSCAN" class="id_link">#</a></dt><dd><p> Enables or disables the query planner's use of <acronym class="acronym">TID</acronym> scan plan types. The default is <code class="literal">on</code>. </p></dd></dl></div></div><div class="sect2" id="RUNTIME-CONFIG-QUERY-CONSTANTS"><div class="titlepage"><div><div><h3 class="title">19.7.2. Planner Cost Constants <a href="#RUNTIME-CONFIG-QUERY-CONSTANTS" class="id_link">#</a></h3></div></div></div><p> The <em class="firstterm">cost</em> variables described in this section are measured on an arbitrary scale. Only their relative values matter, hence scaling them all up or down by the same factor will result in no change in the planner's choices. By default, these cost variables are based on the cost of sequential page fetches; that is, <code class="varname">seq_page_cost</code> is conventionally set to <code class="literal">1.0</code> and the other cost variables are set with reference to that. But you can use a different scale if you prefer, such as actual execution times in milliseconds on a particular machine. </p><div class="note"><h3 class="title">Note</h3><p> Unfortunately, there is no well-defined method for determining ideal values for the cost variables. They are best treated as averages over the entire mix of queries that a particular installation will receive. This means that changing them on the basis of just a few experiments is very risky. </p></div><div class="variablelist"><dl class="variablelist"><dt id="GUC-SEQ-PAGE-COST"><span class="term"><code class="varname">seq_page_cost</code> (<code class="type">floating point</code>) <a id="id-1.6.6.10.3.4.1.1.3" class="indexterm"></a> </span> <a href="#GUC-SEQ-PAGE-COST" class="id_link">#</a></dt><dd><p> Sets the planner's estimate of the cost of a disk page fetch that is part of a series of sequential fetches. The default is 1.0. This value can be overridden for tables and indexes in a particular tablespace by setting the tablespace parameter of the same name (see <a class="xref" href="sql-altertablespace.html" title="ALTER TABLESPACE"><span class="refentrytitle">ALTER TABLESPACE</span></a>). </p></dd><dt id="GUC-RANDOM-PAGE-COST"><span class="term"><code class="varname">random_page_cost</code> (<code class="type">floating point</code>) <a id="id-1.6.6.10.3.4.2.1.3" class="indexterm"></a> </span> <a href="#GUC-RANDOM-PAGE-COST" class="id_link">#</a></dt><dd><p> Sets the planner's estimate of the cost of a non-sequentially-fetched disk page. The default is 4.0. This value can be overridden for tables and indexes in a particular tablespace by setting the tablespace parameter of the same name (see <a class="xref" href="sql-altertablespace.html" title="ALTER TABLESPACE"><span class="refentrytitle">ALTER TABLESPACE</span></a>). </p><p> Reducing this value relative to <code class="varname">seq_page_cost</code> will cause the system to prefer index scans; raising it will make index scans look relatively more expensive. You can raise or lower both values together to change the importance of disk I/O costs relative to CPU costs, which are described by the following parameters. </p><p> Random access to mechanical disk storage is normally much more expensive than four times sequential access. However, a lower default is used (4.0) because the majority of random accesses to disk, such as indexed reads, are assumed to be in cache. The default value can be thought of as modeling random access as 40 times slower than sequential, while expecting 90% of random reads to be cached. </p><p> If you believe a 90% cache rate is an incorrect assumption for your workload, you can increase random_page_cost to better reflect the true cost of random storage reads. Correspondingly, if your data is likely to be completely in cache, such as when the database is smaller than the total server memory, decreasing random_page_cost can be appropriate. Storage that has a low random read cost relative to sequential, e.g., solid-state drives, might also be better modeled with a lower value for random_page_cost, e.g., <code class="literal">1.1</code>. </p><div class="tip"><h3 class="title">Tip</h3><p> Although the system will let you set <code class="varname">random_page_cost</code> to less than <code class="varname">seq_page_cost</code>, it is not physically sensible to do so. However, setting them equal makes sense if the database is entirely cached in RAM, since in that case there is no penalty for touching pages out of sequence. Also, in a heavily-cached database you should lower both values relative to the CPU parameters, since the cost of fetching a page already in RAM is much smaller than it would normally be. </p></div></dd><dt id="GUC-CPU-TUPLE-COST"><span class="term"><code class="varname">cpu_tuple_cost</code> (<code class="type">floating point</code>) <a id="id-1.6.6.10.3.4.3.1.3" class="indexterm"></a> </span> <a href="#GUC-CPU-TUPLE-COST" class="id_link">#</a></dt><dd><p> Sets the planner's estimate of the cost of processing each row during a query. The default is 0.01. </p></dd><dt id="GUC-CPU-INDEX-TUPLE-COST"><span class="term"><code class="varname">cpu_index_tuple_cost</code> (<code class="type">floating point</code>) <a id="id-1.6.6.10.3.4.4.1.3" class="indexterm"></a> </span> <a href="#GUC-CPU-INDEX-TUPLE-COST" class="id_link">#</a></dt><dd><p> Sets the planner's estimate of the cost of processing each index entry during an index scan. The default is 0.005. </p></dd><dt id="GUC-CPU-OPERATOR-COST"><span class="term"><code class="varname">cpu_operator_cost</code> (<code class="type">floating point</code>) <a id="id-1.6.6.10.3.4.5.1.3" class="indexterm"></a> </span> <a href="#GUC-CPU-OPERATOR-COST" class="id_link">#</a></dt><dd><p> Sets the planner's estimate of the cost of processing each operator or function executed during a query. The default is 0.0025. </p></dd><dt id="GUC-PARALLEL-SETUP-COST"><span class="term"><code class="varname">parallel_setup_cost</code> (<code class="type">floating point</code>) <a id="id-1.6.6.10.3.4.6.1.3" class="indexterm"></a> </span> <a href="#GUC-PARALLEL-SETUP-COST" class="id_link">#</a></dt><dd><p> Sets the planner's estimate of the cost of launching parallel worker processes. The default is 1000. </p></dd><dt id="GUC-PARALLEL-TUPLE-COST"><span class="term"><code class="varname">parallel_tuple_cost</code> (<code class="type">floating point</code>) <a id="id-1.6.6.10.3.4.7.1.3" class="indexterm"></a> </span> <a href="#GUC-PARALLEL-TUPLE-COST" class="id_link">#</a></dt><dd><p> Sets the planner's estimate of the cost of transferring one tuple from a parallel worker process to another process. The default is 0.1. </p></dd><dt id="GUC-MIN-PARALLEL-TABLE-SCAN-SIZE"><span class="term"><code class="varname">min_parallel_table_scan_size</code> (<code class="type">integer</code>) <a id="id-1.6.6.10.3.4.8.1.3" class="indexterm"></a> </span> <a href="#GUC-MIN-PARALLEL-TABLE-SCAN-SIZE" class="id_link">#</a></dt><dd><p> Sets the minimum amount of table data that must be scanned in order for a parallel scan to be considered. For a parallel sequential scan, the amount of table data scanned is always equal to the size of the table, but when indexes are used the amount of table data scanned will normally be less. If this value is specified without units, it is taken as blocks, that is <code class="symbol">BLCKSZ</code> bytes, typically 8kB. The default is 8 megabytes (<code class="literal">8MB</code>). </p></dd><dt id="GUC-MIN-PARALLEL-INDEX-SCAN-SIZE"><span class="term"><code class="varname">min_parallel_index_scan_size</code> (<code class="type">integer</code>) <a id="id-1.6.6.10.3.4.9.1.3" class="indexterm"></a> </span> <a href="#GUC-MIN-PARALLEL-INDEX-SCAN-SIZE" class="id_link">#</a></dt><dd><p> Sets the minimum amount of index data that must be scanned in order for a parallel scan to be considered. Note that a parallel index scan typically won't touch the entire index; it is the number of pages which the planner believes will actually be touched by the scan which is relevant. This parameter is also used to decide whether a particular index can participate in a parallel vacuum. See <a class="xref" href="sql-vacuum.html" title="VACUUM"><span class="refentrytitle">VACUUM</span></a>. If this value is specified without units, it is taken as blocks, that is <code class="symbol">BLCKSZ</code> bytes, typically 8kB. The default is 512 kilobytes (<code class="literal">512kB</code>). </p></dd><dt id="GUC-EFFECTIVE-CACHE-SIZE"><span class="term"><code class="varname">effective_cache_size</code> (<code class="type">integer</code>) <a id="id-1.6.6.10.3.4.10.1.3" class="indexterm"></a> </span> <a href="#GUC-EFFECTIVE-CACHE-SIZE" class="id_link">#</a></dt><dd><p> Sets the planner's assumption about the effective size of the disk cache that is available to a single query. This is factored into estimates of the cost of using an index; a higher value makes it more likely index scans will be used, a lower value makes it more likely sequential scans will be used. When setting this parameter you should consider both <span class="productname">PostgreSQL</span>'s shared buffers and the portion of the kernel's disk cache that will be used for <span class="productname">PostgreSQL</span> data files, though some data might exist in both places. Also, take into account the expected number of concurrent queries on different tables, since they will have to share the available space. This parameter has no effect on the size of shared memory allocated by <span class="productname">PostgreSQL</span>, nor does it reserve kernel disk cache; it is used only for estimation purposes. The system also does not assume data remains in the disk cache between queries. If this value is specified without units, it is taken as blocks, that is <code class="symbol">BLCKSZ</code> bytes, typically 8kB. The default is 4 gigabytes (<code class="literal">4GB</code>). (If <code class="symbol">BLCKSZ</code> is not 8kB, the default value scales proportionally to it.) </p></dd><dt id="GUC-JIT-ABOVE-COST"><span class="term"><code class="varname">jit_above_cost</code> (<code class="type">floating point</code>) <a id="id-1.6.6.10.3.4.11.1.3" class="indexterm"></a> </span> <a href="#GUC-JIT-ABOVE-COST" class="id_link">#</a></dt><dd><p> Sets the query cost above which JIT compilation is activated, if enabled (see <a class="xref" href="jit.html" title="Chapter 30. Just-in-Time Compilation (JIT)">Chapter 30</a>). Performing <acronym class="acronym">JIT</acronym> costs planning time but can accelerate query execution. Setting this to <code class="literal">-1</code> disables JIT compilation. The default is <code class="literal">100000</code>. </p></dd><dt id="GUC-JIT-INLINE-ABOVE-COST"><span class="term"><code class="varname">jit_inline_above_cost</code> (<code class="type">floating point</code>) <a id="id-1.6.6.10.3.4.12.1.3" class="indexterm"></a> </span> <a href="#GUC-JIT-INLINE-ABOVE-COST" class="id_link">#</a></dt><dd><p> Sets the query cost above which JIT compilation attempts to inline functions and operators. Inlining adds planning time, but can improve execution speed. It is not meaningful to set this to less than <code class="varname">jit_above_cost</code>. Setting this to <code class="literal">-1</code> disables inlining. The default is <code class="literal">500000</code>. </p></dd><dt id="GUC-JIT-OPTIMIZE-ABOVE-COST"><span class="term"><code class="varname">jit_optimize_above_cost</code> (<code class="type">floating point</code>) <a id="id-1.6.6.10.3.4.13.1.3" class="indexterm"></a> </span> <a href="#GUC-JIT-OPTIMIZE-ABOVE-COST" class="id_link">#</a></dt><dd><p> Sets the query cost above which JIT compilation applies expensive optimizations. Such optimization adds planning time, but can improve execution speed. It is not meaningful to set this to less than <code class="varname">jit_above_cost</code>, and it is unlikely to be beneficial to set it to more than <code class="varname">jit_inline_above_cost</code>. Setting this to <code class="literal">-1</code> disables expensive optimizations. The default is <code class="literal">500000</code>. </p></dd></dl></div></div><div class="sect2" id="RUNTIME-CONFIG-QUERY-GEQO"><div class="titlepage"><div><div><h3 class="title">19.7.3. Genetic Query Optimizer <a href="#RUNTIME-CONFIG-QUERY-GEQO" class="id_link">#</a></h3></div></div></div><p> The genetic query optimizer (GEQO) is an algorithm that does query planning using heuristic searching. This reduces planning time for complex queries (those joining many relations), at the cost of producing plans that are sometimes inferior to those found by the normal exhaustive-search algorithm. For more information see <a class="xref" href="geqo.html" title="Chapter 60. Genetic Query Optimizer">Chapter 60</a>. </p><div class="variablelist"><dl class="variablelist"><dt id="GUC-GEQO"><span class="term"><code class="varname">geqo</code> (<code class="type">boolean</code>) <a id="id-1.6.6.10.4.3.1.1.3" class="indexterm"></a> <a id="id-1.6.6.10.4.3.1.1.4" class="indexterm"></a> <a id="id-1.6.6.10.4.3.1.1.5" class="indexterm"></a> </span> <a href="#GUC-GEQO" class="id_link">#</a></dt><dd><p> Enables or disables genetic query optimization. This is on by default. It is usually best not to turn it off in production; the <code class="varname">geqo_threshold</code> variable provides more granular control of GEQO. </p></dd><dt id="GUC-GEQO-THRESHOLD"><span class="term"><code class="varname">geqo_threshold</code> (<code class="type">integer</code>) <a id="id-1.6.6.10.4.3.2.1.3" class="indexterm"></a> </span> <a href="#GUC-GEQO-THRESHOLD" class="id_link">#</a></dt><dd><p> Use genetic query optimization to plan queries with at least this many <code class="literal">FROM</code> items involved. (Note that a <code class="literal">FULL OUTER JOIN</code> construct counts as only one <code class="literal">FROM</code> item.) The default is 12. For simpler queries it is usually best to use the regular, exhaustive-search planner, but for queries with many tables the exhaustive search takes too long, often longer than the penalty of executing a suboptimal plan. Thus, a threshold on the size of the query is a convenient way to manage use of GEQO. </p></dd><dt id="GUC-GEQO-EFFORT"><span class="term"><code class="varname">geqo_effort</code> (<code class="type">integer</code>) <a id="id-1.6.6.10.4.3.3.1.3" class="indexterm"></a> </span> <a href="#GUC-GEQO-EFFORT" class="id_link">#</a></dt><dd><p> Controls the trade-off between planning time and query plan quality in GEQO. This variable must be an integer in the range from 1 to 10. The default value is five. Larger values increase the time spent doing query planning, but also increase the likelihood that an efficient query plan will be chosen. </p><p> <code class="varname">geqo_effort</code> doesn't actually do anything directly; it is only used to compute the default values for the other variables that influence GEQO behavior (described below). If you prefer, you can set the other parameters by hand instead. </p></dd><dt id="GUC-GEQO-POOL-SIZE"><span class="term"><code class="varname">geqo_pool_size</code> (<code class="type">integer</code>) <a id="id-1.6.6.10.4.3.4.1.3" class="indexterm"></a> </span> <a href="#GUC-GEQO-POOL-SIZE" class="id_link">#</a></dt><dd><p> Controls the pool size used by GEQO, that is the number of individuals in the genetic population. It must be at least two, and useful values are typically 100 to 1000. If it is set to zero (the default setting) then a suitable value is chosen based on <code class="varname">geqo_effort</code> and the number of tables in the query. </p></dd><dt id="GUC-GEQO-GENERATIONS"><span class="term"><code class="varname">geqo_generations</code> (<code class="type">integer</code>) <a id="id-1.6.6.10.4.3.5.1.3" class="indexterm"></a> </span> <a href="#GUC-GEQO-GENERATIONS" class="id_link">#</a></dt><dd><p> Controls the number of generations used by GEQO, that is the number of iterations of the algorithm. It must be at least one, and useful values are in the same range as the pool size. If it is set to zero (the default setting) then a suitable value is chosen based on <code class="varname">geqo_pool_size</code>. </p></dd><dt id="GUC-GEQO-SELECTION-BIAS"><span class="term"><code class="varname">geqo_selection_bias</code> (<code class="type">floating point</code>) <a id="id-1.6.6.10.4.3.6.1.3" class="indexterm"></a> </span> <a href="#GUC-GEQO-SELECTION-BIAS" class="id_link">#</a></dt><dd><p> Controls the selection bias used by GEQO. The selection bias is the selective pressure within the population. Values can be from 1.50 to 2.00; the latter is the default. </p></dd><dt id="GUC-GEQO-SEED"><span class="term"><code class="varname">geqo_seed</code> (<code class="type">floating point</code>) <a id="id-1.6.6.10.4.3.7.1.3" class="indexterm"></a> </span> <a href="#GUC-GEQO-SEED" class="id_link">#</a></dt><dd><p> Controls the initial value of the random number generator used by GEQO to select random paths through the join order search space. The value can range from zero (the default) to one. Varying the value changes the set of join paths explored, and may result in a better or worse best path being found. </p></dd></dl></div></div><div class="sect2" id="RUNTIME-CONFIG-QUERY-OTHER"><div class="titlepage"><div><div><h3 class="title">19.7.4. Other Planner Options <a href="#RUNTIME-CONFIG-QUERY-OTHER" class="id_link">#</a></h3></div></div></div><div class="variablelist"><dl class="variablelist"><dt id="GUC-DEFAULT-STATISTICS-TARGET"><span class="term"><code class="varname">default_statistics_target</code> (<code class="type">integer</code>) <a id="id-1.6.6.10.5.2.1.1.3" class="indexterm"></a> </span> <a href="#GUC-DEFAULT-STATISTICS-TARGET" class="id_link">#</a></dt><dd><p> Sets the default statistics target for table columns without a column-specific target set via <code class="command">ALTER TABLE SET STATISTICS</code>. Larger values increase the time needed to do <code class="command">ANALYZE</code>, but might improve the quality of the planner's estimates. The default is 100. For more information on the use of statistics by the <span class="productname">PostgreSQL</span> query planner, refer to <a class="xref" href="planner-stats.html" title="14.2. Statistics Used by the Planner">Section 14.2</a>. </p></dd><dt id="GUC-CONSTRAINT-EXCLUSION"><span class="term"><code class="varname">constraint_exclusion</code> (<code class="type">enum</code>) <a id="id-1.6.6.10.5.2.2.1.3" class="indexterm"></a> <a id="id-1.6.6.10.5.2.2.1.4" class="indexterm"></a> </span> <a href="#GUC-CONSTRAINT-EXCLUSION" class="id_link">#</a></dt><dd><p> Controls the query planner's use of table constraints to optimize queries. The allowed values of <code class="varname">constraint_exclusion</code> are <code class="literal">on</code> (examine constraints for all tables), <code class="literal">off</code> (never examine constraints), and <code class="literal">partition</code> (examine constraints only for inheritance child tables and <code class="literal">UNION ALL</code> subqueries). <code class="literal">partition</code> is the default setting. It is often used with traditional inheritance trees to improve performance. </p><p> When this parameter allows it for a particular table, the planner compares query conditions with the table's <code class="literal">CHECK</code> constraints, and omits scanning tables for which the conditions contradict the constraints. For example: </p><pre class="programlisting"> CREATE TABLE parent(key integer, ...); CREATE TABLE child1000(check (key between 1000 and 1999)) INHERITS(parent); CREATE TABLE child2000(check (key between 2000 and 2999)) INHERITS(parent); ... SELECT * FROM parent WHERE key = 2400; </pre><p> With constraint exclusion enabled, this <code class="command">SELECT</code> will not scan <code class="structname">child1000</code> at all, improving performance. </p><p> Currently, constraint exclusion is enabled by default only for cases that are often used to implement table partitioning via inheritance trees. Turning it on for all tables imposes extra planning overhead that is quite noticeable on simple queries, and most often will yield no benefit for simple queries. If you have no tables that are partitioned using traditional inheritance, you might prefer to turn it off entirely. (Note that the equivalent feature for partitioned tables is controlled by a separate parameter, <a class="xref" href="runtime-config-query.html#GUC-ENABLE-PARTITION-PRUNING">enable_partition_pruning</a>.) </p><p> Refer to <a class="xref" href="ddl-partitioning.html#DDL-PARTITIONING-CONSTRAINT-EXCLUSION" title="5.12.5. Partitioning and Constraint Exclusion">Section 5.12.5</a> for more information on using constraint exclusion to implement partitioning. </p></dd><dt id="GUC-CURSOR-TUPLE-FRACTION"><span class="term"><code class="varname">cursor_tuple_fraction</code> (<code class="type">floating point</code>) <a id="id-1.6.6.10.5.2.3.1.3" class="indexterm"></a> </span> <a href="#GUC-CURSOR-TUPLE-FRACTION" class="id_link">#</a></dt><dd><p> Sets the planner's estimate of the fraction of a cursor's rows that will be retrieved. The default is 0.1. Smaller values of this setting bias the planner towards using <span class="quote">“<span class="quote">fast start</span>”</span> plans for cursors, which will retrieve the first few rows quickly while perhaps taking a long time to fetch all rows. Larger values put more emphasis on the total estimated time. At the maximum setting of 1.0, cursors are planned exactly like regular queries, considering only the total estimated time and not how soon the first rows might be delivered. </p></dd><dt id="GUC-FROM-COLLAPSE-LIMIT"><span class="term"><code class="varname">from_collapse_limit</code> (<code class="type">integer</code>) <a id="id-1.6.6.10.5.2.4.1.3" class="indexterm"></a> </span> <a href="#GUC-FROM-COLLAPSE-LIMIT" class="id_link">#</a></dt><dd><p> The planner will merge sub-queries into upper queries if the resulting <code class="literal">FROM</code> list would have no more than this many items. Smaller values reduce planning time but might yield inferior query plans. The default is eight. For more information see <a class="xref" href="explicit-joins.html" title="14.3. Controlling the Planner with Explicit JOIN Clauses">Section 14.3</a>. </p><p> Setting this value to <a class="xref" href="runtime-config-query.html#GUC-GEQO-THRESHOLD">geqo_threshold</a> or more may trigger use of the GEQO planner, resulting in non-optimal plans. See <a class="xref" href="runtime-config-query.html#RUNTIME-CONFIG-QUERY-GEQO" title="19.7.3. Genetic Query Optimizer">Section 19.7.3</a>. </p></dd><dt id="GUC-JIT"><span class="term"><code class="varname">jit</code> (<code class="type">boolean</code>) <a id="id-1.6.6.10.5.2.5.1.3" class="indexterm"></a> </span> <a href="#GUC-JIT" class="id_link">#</a></dt><dd><p> Determines whether <acronym class="acronym">JIT</acronym> compilation may be used by <span class="productname">PostgreSQL</span>, if available (see <a class="xref" href="jit.html" title="Chapter 30. Just-in-Time Compilation (JIT)">Chapter 30</a>). The default is <code class="literal">on</code>. </p></dd><dt id="GUC-JOIN-COLLAPSE-LIMIT"><span class="term"><code class="varname">join_collapse_limit</code> (<code class="type">integer</code>) <a id="id-1.6.6.10.5.2.6.1.3" class="indexterm"></a> </span> <a href="#GUC-JOIN-COLLAPSE-LIMIT" class="id_link">#</a></dt><dd><p> The planner will rewrite explicit <code class="literal">JOIN</code> constructs (except <code class="literal">FULL JOIN</code>s) into lists of <code class="literal">FROM</code> items whenever a list of no more than this many items would result. Smaller values reduce planning time but might yield inferior query plans. </p><p> By default, this variable is set the same as <code class="varname">from_collapse_limit</code>, which is appropriate for most uses. Setting it to 1 prevents any reordering of explicit <code class="literal">JOIN</code>s. Thus, the explicit join order specified in the query will be the actual order in which the relations are joined. Because the query planner does not always choose the optimal join order, advanced users can elect to temporarily set this variable to 1, and then specify the join order they desire explicitly. For more information see <a class="xref" href="explicit-joins.html" title="14.3. Controlling the Planner with Explicit JOIN Clauses">Section 14.3</a>. </p><p> Setting this value to <a class="xref" href="runtime-config-query.html#GUC-GEQO-THRESHOLD">geqo_threshold</a> or more may trigger use of the GEQO planner, resulting in non-optimal plans. See <a class="xref" href="runtime-config-query.html#RUNTIME-CONFIG-QUERY-GEQO" title="19.7.3. Genetic Query Optimizer">Section 19.7.3</a>. </p></dd><dt id="GUC-PLAN-CACHE-MODE"><span class="term"><code class="varname">plan_cache_mode</code> (<code class="type">enum</code>) <a id="id-1.6.6.10.5.2.7.1.3" class="indexterm"></a> </span> <a href="#GUC-PLAN-CACHE-MODE" class="id_link">#</a></dt><dd><p> Prepared statements (either explicitly prepared or implicitly generated, for example by PL/pgSQL) can be executed using custom or generic plans. Custom plans are made afresh for each execution using its specific set of parameter values, while generic plans do not rely on the parameter values and can be re-used across executions. Thus, use of a generic plan saves planning time, but if the ideal plan depends strongly on the parameter values then a generic plan may be inefficient. The choice between these options is normally made automatically, but it can be overridden with <code class="varname">plan_cache_mode</code>. The allowed values are <code class="literal">auto</code> (the default), <code class="literal">force_custom_plan</code> and <code class="literal">force_generic_plan</code>. This setting is considered when a cached plan is to be executed, not when it is prepared. For more information see <a class="xref" href="sql-prepare.html" title="PREPARE"><span class="refentrytitle">PREPARE</span></a>. </p></dd><dt id="GUC-RECURSIVE-WORKTABLE-FACTOR"><span class="term"><code class="varname">recursive_worktable_factor</code> (<code class="type">floating point</code>) <a id="id-1.6.6.10.5.2.8.1.3" class="indexterm"></a> </span> <a href="#GUC-RECURSIVE-WORKTABLE-FACTOR" class="id_link">#</a></dt><dd><p> Sets the planner's estimate of the average size of the working table of a <a class="link" href="queries-with.html#QUERIES-WITH-RECURSIVE" title="7.8.2. Recursive Queries">recursive query</a>, as a multiple of the estimated size of the initial non-recursive term of the query. This helps the planner choose the most appropriate method for joining the working table to the query's other tables. The default value is <code class="literal">10.0</code>. A smaller value such as <code class="literal">1.0</code> can be helpful when the recursion has low <span class="quote">“<span class="quote">fan-out</span>”</span> from one step to the next, as for example in shortest-path queries. Graph analytics queries may benefit from larger-than-default values. </p></dd></dl></div></div></div><div class="navfooter"><hr /><table width="100%" summary="Navigation footer"><tr><td width="40%" align="left"><a accesskey="p" href="runtime-config-replication.html" title="19.6. Replication">Prev</a> </td><td width="20%" align="center"><a accesskey="u" href="runtime-config.html" title="Chapter 19. Server Configuration">Up</a></td><td width="40%" align="right"> <a accesskey="n" href="runtime-config-logging.html" title="19.8. Error Reporting and Logging">Next</a></td></tr><tr><td width="40%" align="left" valign="top">19.6. Replication </td><td width="20%" align="center"><a accesskey="h" href="index.html" title="PostgreSQL 18devel Documentation">Home</a></td><td width="40%" align="right" valign="top"> 19.8. Error Reporting and Logging</td></tr></table></div></body></html> [application/octet-stream] v2_enable_indexscan_docs.patch (1.2K, ../../CAApHDvrR=0ExMOEQvnwWfck2NSk=_pktwNDvybYS-ziB74kT1w@mail.gmail.com/3-v2_enable_indexscan_docs.patch) download | inline diff: diff --git a/doc/src/sgml/config.sgml b/doc/src/sgml/config.sgml index dc401087dc..d54f904956 100644 --- a/doc/src/sgml/config.sgml +++ b/doc/src/sgml/config.sgml @@ -5442,8 +5442,9 @@ ANY <replaceable class="parameter">num_sync</replaceable> ( <replaceable class=" </term> <listitem> <para> - Enables or disables the query planner's use of index-scan plan - types. The default is <literal>on</literal>. + Enables or disables the query planner's use of index-scan and + index-only-scan plan types. The default is <literal>on</literal>. + Also see <xref linkend="guc-enable-indexonlyscan"/>. </para> </listitem> </varlistentry> @@ -5458,7 +5459,9 @@ ANY <replaceable class="parameter">num_sync</replaceable> ( <replaceable class=" <para> Enables or disables the query planner's use of index-only-scan plan types (see <xref linkend="indexes-index-only-scans"/>). - The default is <literal>on</literal>. + The default is <literal>on</literal>. The + <xref linkend="guc-enable-indexscan"/> setting must also be + enabled to have the query planner consider index-only-scans. </para> </listitem> </varlistentry> ^ permalink raw reply [nested|flat] 21+ messages in thread
* Re: EXPLAIN IndexOnlyScan shows disabled when enable_indexonlyscan=on @ 2024-10-29 00:29 David G. Johnston <[email protected]> parent: David Rowley <[email protected]> 1 sibling, 0 replies; 21+ messages in thread From: David G. Johnston @ 2024-10-29 00:29 UTC (permalink / raw) To: David Rowley <[email protected]>; +Cc: Melanie Plageman <[email protected]>; pgsql-hackers; Robert Haas <[email protected]> On Mon, Oct 28, 2024 at 3:54 PM David Rowley <[email protected]> wrote: > On Wed, 23 Oct 2024 at 13:51, David G. Johnston > <[email protected]> wrote: > > Went with a slightly different wording that seems to flow better with > the xrefs I added between the two options. > > - Enables or disables the query planner's use of index-scan plan > - types. The default is <literal>on</literal>. > + Enables or disables the query planner's use of all index-scan > related plan > > I'm concerned about the wording "all index-scan related". It's not > that clear if that would include Bitmap Index Scans or not. That was partially the point of writing "all" there - absent other information, and seeing how index-only scans were treated, I presumed it was indeed actually or effectively a switch for all. If it is not it should be made clear which node types with the word index in them are not affected. I think > it's better to explicitly mention index-only-scans to make it clear > which nodes are affected. > I hadn't considered Bitmap Index Scans but I would expect if you do not use index scans then the ability to produce bitmaps from them would be precluded. I could see pointing out, in enable_bitmapscan, that enable_bitmapscan is effectively disabled (for index inputs) when enable_indexscan is set to off. Then, in enable_indexscan, add a "see also" to enable_bitmapscan with a brief reason as well. Is there a listing of all node types produced by PostgreSQL (with the explain output naming) along with which ones are affected by which enable_* knobs (possibly multiple for something like Bitmap Index Scan)? > + types. The default is <literal>on</literal>. The > index-only-scan plan types > + can be independently disabled by setting <xref > linkend="guc-enable-indexonlyscan"/> > + to <literal>off</literal>. > > I wondered if it's better to reference the enable_indexonlyscan GUC > here rather than document what enable_indexonlyscan does from the > enable_indexscan docs. Maybe just a "Also see enable_indexonlyscans." > could be added? > I prefer to briefly explain why we advise the reader to go "see also" here. > - The default is <literal>on</literal>. > + The default is <literal>on</literal>. However, this setting > has no effect if > + <xref linkend="guc-enable-indexscan"/> is set to > <literal>off</literal>. > > Could we just add "The <xref linkend="guc-enable-indexscan"/> setting > must also be enabled to have the query planner consider > index-only-scans"? > I'd like to stick with a conjunction there but agree the "must be enabled" wording is preferrable, avoiding the double-negative. "The default is on, but the <xref> setting must also be enabled." The 'to have the...' part seems to just be redundant. David J. ^ permalink raw reply [nested|flat] 21+ messages in thread
* Re: EXPLAIN IndexOnlyScan shows disabled when enable_indexonlyscan=on @ 2024-10-29 01:40 David G. Johnston <[email protected]> parent: David Rowley <[email protected]> 1 sibling, 1 reply; 21+ messages in thread From: David G. Johnston @ 2024-10-29 01:40 UTC (permalink / raw) To: David Rowley <[email protected]>; +Cc: Melanie Plageman <[email protected]>; pgsql-hackers; Robert Haas <[email protected]> On Mon, Oct 28, 2024 at 3:54 PM David Rowley <[email protected]> wrote: > > I've attached that in patch form. > > - Enables or disables the query planner's use of index-scan plan - types. The default is <literal>on</literal>. + Enables or disables the query planner's use of index-scan and + index-only-scan plan types. The default is <literal>on</literal>. + Also see <xref linkend="guc-enable-indexonlyscan"/>. I think the original wording "index-scan plan types" is what is confusing me. The plural types is turning index-scan plan into a category of plans rather than the single plan type "index scan". Your proposed wording actually (accidentally?) fixes this because now the plural types actually refers to two individual plan nodes, "index scan" and "index-only scan". The hyphenation still reads a bit odd but ok. I am ok with this revision (and the patch as a whole) I suppose but I still feel like something is missing here. Though probably that something would fit better in an overview page rather than trying to get the settings to explain all this to the reader. David J. ^ permalink raw reply [nested|flat] 21+ messages in thread
* Re: EXPLAIN IndexOnlyScan shows disabled when enable_indexonlyscan=on @ 2024-10-29 03:06 David Rowley <[email protected]> parent: David G. Johnston <[email protected]> 0 siblings, 0 replies; 21+ messages in thread From: David Rowley @ 2024-10-29 03:06 UTC (permalink / raw) To: David G. Johnston <[email protected]>; +Cc: Melanie Plageman <[email protected]>; pgsql-hackers; Robert Haas <[email protected]> On Tue, 29 Oct 2024 at 14:41, David G. Johnston <[email protected]> wrote: > > On Mon, Oct 28, 2024 at 3:54 PM David Rowley <[email protected]> wrote: > - Enables or disables the query planner's use of index-scan plan > - types. The default is <literal>on</literal>. > + Enables or disables the query planner's use of index-scan and > + index-only-scan plan types. The default is <literal>on</literal>. > + Also see <xref linkend="guc-enable-indexonlyscan"/>. > > I think the original wording "index-scan plan types" is what is confusing me. The plural types is turning index-scan plan into a category of plans rather than the single plan type "index scan". > > Your proposed wording actually (accidentally?) fixes this because now the plural types actually refers to two individual plan nodes, "index scan" and "index-only scan". I can't really vouch for the original wording as I didn't write it. I agree the original use of "types" as a plural is strange and it's not all that clear what that includes. Perhaps it was an attempt to mean index and index-only scans > The hyphenation still reads a bit odd but ok. I'm not sure where the hyphenated form of "index-scan" comes from and I admit that I blindly copied that form when I wrote "index-only-scans". I'd much prefer we used <literal>Index Scan</literal> and <literal>Index Only Scan</literal> so it could more easily be matched up to what's shown in EXPLAIN. I don't think it's up to this patch to change that, so I've just copied the existing form. I was also warded off using the node name from EXPLAIN in [1], and on checking the validity of the complaint, it seems valid. > I am ok with this revision (and the patch as a whole) I suppose but I still feel like something is missing here. Though probably that something would fit better in an overview page rather than trying to get the settings to explain all this to the reader. Thanks. I'll go make it happen. It seems worthy of a backpatch because it seems equally as applicable there, plus to maintain consistency. For the part that seems missing... I'm not sure it's a great excuse, but we've often been quite bad at updating the documentation when making changes to the executor or EXPLAIN. Tom fixed a bunch of stuff in 5caa05749 which was outdated. I think if we wanted to try and do a better job of documenting plan choices and EXPLAIN output, we'd need to consider if the said documentation is worth the additional maintenance burden. It might be quite hard to decide that unless someone went and wrote the documentation first so that we could consider it on its own merit. Whoever does that would have to be willing to have the whole work rejected if we decided it wasn't worth the trouble. It seems like a bit of a thankless task and I'm not motivated to do it. Your pain threshold might be higher than mine, however. David [1] https://www.postgresql.org/message-id/[email protected] ^ permalink raw reply [nested|flat] 21+ messages in thread
* Re: tab complete for COPY populated materialized view TO @ 2025-04-09 09:25 Kirill Reshke <[email protected]> 0 siblings, 1 reply; 21+ messages in thread From: Kirill Reshke @ 2025-04-09 09:25 UTC (permalink / raw) To: jian he <[email protected]>; +Cc: pgsql-hackers On Wed, 9 Apr 2025 at 13:23, jian he <[email protected]> wrote: > > hi. > > we allow the "COPY table TO" command to copy rows from materialized > views in [1]. > The attached patch is to add a tab complete for it. > > [1] https://git.postgresql.org/cgit/postgresql.git/commit/?id=534874fac0b34535c9a5ab9257d6574f78423578 Hi! Patch works good for me, but I noticed that psql COPY <tab> suggests partitioned relation both with and without this patch. Maybe that's not a big problem, if [0] will be pushed. [0] https://www.postgresql.org/message-id/CACJufxHjBPrsbNZAp-DCmwvOE_Gkogb%2Brhfqqe1%3DS5cOHR-V7Q%40mail... -- Best regards, Kirill Reshke ^ permalink raw reply [nested|flat] 21+ messages in thread
* Re: tab complete for COPY populated materialized view TO @ 2025-04-09 10:24 Kirill Reshke <[email protected]> parent: Kirill Reshke <[email protected]> 0 siblings, 1 reply; 21+ messages in thread From: Kirill Reshke @ 2025-04-09 10:24 UTC (permalink / raw) To: Fujii Masao <[email protected]>; +Cc: jian he <[email protected]>; pgsql-hackers On Wed, 9 Apr 2025 at 14:45, Fujii Masao <[email protected]> wrote: > > > > On 2025/04/09 18:25, Kirill Reshke wrote: > > On Wed, 9 Apr 2025 at 13:23, jian he <[email protected]> wrote: > >> > >> hi. > >> > >> we allow the "COPY table TO" command to copy rows from materialized > >> views in [1]. > >> The attached patch is to add a tab complete for it. > >> > >> [1] https://git.postgresql.org/cgit/postgresql.git/commit/?id=534874fac0b34535c9a5ab9257d6574f78423578 > > > > Hi! > > Patch works good for me, but I noticed that psql COPY <tab> suggests > > partitioned relation both with and without this patch. Maybe that's > > not a big problem, if [0] will be pushed. > > Is the partitioned table currently tab-completed for the COPY FROM case? If I'm not mistaken, yes. I double checked. > INSTEAD OF INSERT triggers - though maybe that's overkill? That's wild to me, psql tab completions feature designed to support postgresql not fully, but in frequent cases. So maybe we should keep it stupud. -- Best regards, Kirill Reshke ^ permalink raw reply [nested|flat] 21+ messages in thread
* Re: tab complete for COPY populated materialized view TO @ 2025-04-10 19:19 Kirill Reshke <[email protected]> parent: Kirill Reshke <[email protected]> 0 siblings, 1 reply; 21+ messages in thread From: Kirill Reshke @ 2025-04-10 19:19 UTC (permalink / raw) To: Fujii Masao <[email protected]>; +Cc: jian he <[email protected]>; pgsql-hackers On Thu, 10 Apr 2025 at 20:07, Fujii Masao <[email protected]> wrote: > > > > On 2025/04/09 19:24, Kirill Reshke wrote: > > On Wed, 9 Apr 2025 at 14:45, Fujii Masao <[email protected]> wrote: > >> > >> > >> > >> On 2025/04/09 18:25, Kirill Reshke wrote: > >>> On Wed, 9 Apr 2025 at 13:23, jian he <[email protected]> wrote: > >>>> > >>>> hi. > >>>> > >>>> we allow the "COPY table TO" command to copy rows from materialized > >>>> views in [1]. > >>>> The attached patch is to add a tab complete for it. > >>>> > >>>> [1] https://git.postgresql.org/cgit/postgresql.git/commit/?id=534874fac0b34535c9a5ab9257d6574f78423578 > >>> > >>> Hi! > >>> Patch works good for me, but I noticed that psql COPY <tab> suggests > >>> partitioned relation both with and without this patch. Maybe that's > >>> not a big problem, if [0] will be pushed. > >> > >> Is the partitioned table currently tab-completed for the COPY FROM case? > > > > If I'm not mistaken, yes. I double checked. > > > >> INSTEAD OF INSERT triggers - though maybe that's overkill? > > > > That's wild to me, psql tab completions feature designed to support > > postgresql not fully, but in frequent cases. So maybe we should keep > > it stupud. > > I agree that it's reasonable to exclude such rarely used objects from > tab-completion. How about including just tables, partitioned tables, > foreign tables, and materialized views? > I've attached a patch for that. > > Regards, Patch is ok. However... > If we aim to support tab-completion for all valid targets of both COPY TO and COPY FROM, shouldn't foreign tables also be included? Ah.. Sorry I missed this part of your message initially. No, foreign tables are not supported: ``` reshke=# CREATE FOREIGN TABLE ft (i int) server zz OPTIONS ( filename 'zz.csv', format 'csv' ); reshke=# copy ft to stdout; ERROR: cannot copy from foreign table "ft" HINT: Try the COPY (SELECT ...) TO variant. ``` So we will tab complete for cases that yet to be supported (foreign tables and partitioned tables); What's funny is that copying foreign tables using MV works fine ``` reshke=# create materialized view mv as table ft; SELECT 1 reshke=# copy mv to stdout; 228 ``` -- Best regards, Kirill Reshke ^ permalink raw reply [nested|flat] 21+ messages in thread
* Re: tab complete for COPY populated materialized view TO @ 2025-04-10 19:33 David G. Johnston <[email protected]> parent: Kirill Reshke <[email protected]> 0 siblings, 1 reply; 21+ messages in thread From: David G. Johnston @ 2025-04-10 19:33 UTC (permalink / raw) To: Kirill Reshke <[email protected]>; +Cc: Fujii Masao <[email protected]>; jian he <[email protected]>; pgsql-hackers On Thursday, April 10, 2025, Kirill Reshke <[email protected]> wrote: > On Thu, 10 Apr 2025 at 20:07, Fujii Masao <[email protected]> > wrote: > > > > > > > > On 2025/04/09 19:24, Kirill Reshke wrote: > > > On Wed, 9 Apr 2025 at 14:45, Fujii Masao <[email protected]> > wrote: > > >> > > >> > > >> > > >> On 2025/04/09 18:25, Kirill Reshke wrote: > > >>> On Wed, 9 Apr 2025 at 13:23, jian he <[email protected]> > wrote: > > >>>> > > >>>> hi. > > >>>> > > >>>> we allow the "COPY table TO" command to copy rows from materialized > > >>>> views in [1]. > > >>>> The attached patch is to add a tab complete for it. > > >>>> > > >>>> [1] https://git.postgresql.org/cgit/postgresql.git/commit/?id= > 534874fac0b34535c9a5ab9257d6574f78423578 > > >>> > > >>> Hi! > > >>> Patch works good for me, but I noticed that psql COPY <tab> suggests > > >>> partitioned relation both with and without this patch. Maybe that's > > >>> not a big problem, if [0] will be pushed. > > >> > > >> Is the partitioned table currently tab-completed for the COPY FROM > case? > > > > > > If I'm not mistaken, yes. I double checked. > > > > > >> INSTEAD OF INSERT triggers - though maybe that's overkill? > > > > > > That's wild to me, psql tab completions feature designed to support > > > postgresql not fully, but in frequent cases. So maybe we should keep > > > it stupud. > > > > I agree that it's reasonable to exclude such rarely used objects from > > tab-completion. How about including just tables, partitioned tables, > > foreign tables, and materialized views? > > I've attached a patch for that. > > > > Regards, > > Patch is ok. However... I concur with the premise of the patch. Tab-complete is going to happen before we know whether to/from is specified so the syntax limits our smarts here. > > If we aim to support tab-completion for all valid targets of both COPY TO > and COPY FROM, shouldn't foreign tables also be included? > > Ah.. Sorry I missed this part of your message initially. No, foreign > tables are not supported: They are supported for the From variant; valid completions need only satisfy one of to/from, not both. > > What's funny is that copying foreign tables using MV works fine > > ``` > reshke=# create materialized view mv as table ft; > SELECT 1 > reshke=# copy mv to stdout; > 228 > ``` > I don’t get why this is “funny” or otherwise surprising. David J. ^ permalink raw reply [nested|flat] 21+ messages in thread
* Re: tab complete for COPY populated materialized view TO @ 2025-04-10 19:37 Kirill Reshke <[email protected]> parent: David G. Johnston <[email protected]> 0 siblings, 1 reply; 21+ messages in thread From: Kirill Reshke @ 2025-04-10 19:37 UTC (permalink / raw) To: David G. Johnston <[email protected]>; +Cc: Fujii Masao <[email protected]>; jian he <[email protected]>; pgsql-hackers On Fri, 11 Apr 2025 at 00:33, David G. Johnston <[email protected]> wrote: > > They are supported for the From variant; valid completions need only satisfy one of to/from, not both. > Thank you. If so, then WFM, and I don't have any more objections. -- Best regards, Kirill Reshke ^ permalink raw reply [nested|flat] 21+ messages in thread
* Re: tab complete for COPY populated materialized view TO @ 2025-06-30 09:39 Fujii Masao <[email protected]> parent: Kirill Reshke <[email protected]> 0 siblings, 0 replies; 21+ messages in thread From: Fujii Masao @ 2025-06-30 09:39 UTC (permalink / raw) To: Kirill Reshke <[email protected]>; David G. Johnston <[email protected]>; +Cc: jian he <[email protected]>; pgsql-hackers On 2025/04/11 4:37, Kirill Reshke wrote: > On Fri, 11 Apr 2025 at 00:33, David G. Johnston > <[email protected]> wrote: >> >> They are supported for the From variant; valid completions need only satisfy one of to/from, not both. >> > > Thank you. If so, then WFM, and I don't have any more objections. I've pushed the patch. Thanks! Regards, -- Fujii Masao NTT DATA Japan Corporation ^ permalink raw reply [nested|flat] 21+ messages in thread
end of thread, other threads:[~2025-06-30 09:39 UTC | newest] Thread overview: 21+ messages (download: mbox mbox.gz follow: Atom feed) -- links below jump to the message on this page -- 2024-03-18 08:34 [PATCH v3] Add "Backpatch" regions in wait_event_names.txt Bertrand Drouvot <[email protected]> 2024-03-18 08:34 [PATCH v2] Add "Backpatch" regions in wait_event_names.txt Bertrand Drouvot <[email protected]> 2024-03-18 08:34 [PATCH v3] Add "Backpatch" regions in wait_event_names.txt Bertrand Drouvot <[email protected]> 2024-03-18 08:34 [PATCH v2] Add "Backpatch" regions in wait_event_names.txt Bertrand Drouvot <[email protected]> 2024-03-18 08:34 [PATCH v2] Add "Backpatch" regions in wait_event_names.txt Bertrand Drouvot <[email protected]> 2024-03-18 08:34 [PATCH v3] Add "Backpatch" regions in wait_event_names.txt Bertrand Drouvot <[email protected]> 2024-10-22 01:32 Re: EXPLAIN IndexOnlyScan shows disabled when enable_indexonlyscan=on David Rowley <[email protected]> 2024-10-22 01:46 ` EXPLAIN IndexOnlyScan shows disabled when enable_indexonlyscan=on David G. Johnston <[email protected]> 2024-10-22 02:20 ` Re: EXPLAIN IndexOnlyScan shows disabled when enable_indexonlyscan=on David Rowley <[email protected]> 2024-10-22 02:40 ` Re: EXPLAIN IndexOnlyScan shows disabled when enable_indexonlyscan=on David G. Johnston <[email protected]> 2024-10-23 00:50 ` Re: EXPLAIN IndexOnlyScan shows disabled when enable_indexonlyscan=on David G. Johnston <[email protected]> 2024-10-28 22:54 ` Re: EXPLAIN IndexOnlyScan shows disabled when enable_indexonlyscan=on David Rowley <[email protected]> 2024-10-29 00:29 ` Re: EXPLAIN IndexOnlyScan shows disabled when enable_indexonlyscan=on David G. Johnston <[email protected]> 2024-10-29 01:40 ` Re: EXPLAIN IndexOnlyScan shows disabled when enable_indexonlyscan=on David G. Johnston <[email protected]> 2024-10-29 03:06 ` Re: EXPLAIN IndexOnlyScan shows disabled when enable_indexonlyscan=on David Rowley <[email protected]> 2025-04-09 09:25 Re: tab complete for COPY populated materialized view TO Kirill Reshke <[email protected]> 2025-04-09 10:24 ` Re: tab complete for COPY populated materialized view TO Kirill Reshke <[email protected]> 2025-04-10 19:19 ` Re: tab complete for COPY populated materialized view TO Kirill Reshke <[email protected]> 2025-04-10 19:33 ` Re: tab complete for COPY populated materialized view TO David G. Johnston <[email protected]> 2025-04-10 19:37 ` Re: tab complete for COPY populated materialized view TO Kirill Reshke <[email protected]> 2025-06-30 09:39 ` Re: tab complete for COPY populated materialized view TO Fujii Masao <[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