pgsql: Add Result Cache executor node

link below for the discussion on the "Result Cache" name. Author: David Rowley Reviewed-by: Andy Fan, Justin Pryzby, Zhihong Yu Tested-By: Konstantin Knizhnik Discussion: https://postgr.es/m/CAApHDvrPcQyQdWERGYWx8J%2B2DLUNgXu%2BfOSbQ1UscxrunyXyrQ%40mail.gmail.com Discussion: https://postgr.es/

Re: pgsql: Extended statistics on expressions

Hi Tomas, I'm debugging a crash after running sqllancer on current master. The first bad commit seems to be this one. The crash stack trace is: Program received signal SIGSEGV, Segmentation fault. pg_detoast_datum_packed (datum=0x5) at fmgr.c:1759 1759 if (VARATT_IS_COMPRESSED(datum) ||

pgsql: Allow estimate_num_groups() to pass back further details about t

to add support for clauselist_selectivity() and clauselist_selectivity_ext(). However, if this is required in the future then the same struct being added here should be fine to use as a new output argument for those functions too. Author: David Rowley Discussion: https://postgr.es/m/CAApHDvqQqpk=1w

pgsql: Fix compiler warning in unistr function

Fix compiler warning in unistr function Some compilers are not aware that elog/ereport ERROR does not return. Branch -- master Details --- https://git.postgresql.org/pg/commitdiff/efd9d92bb39c74c2aded64fc08e2d601ce20c39d Modified Files -- src/backend/utils/adt/varlena.c | 1

Re: pgsql: Implement pipeline mode in libpq

Hi Alvaro, On Tue, 16 Mar 2021 at 10:20, Alvaro Herrera wrote: > > Implement pipeline mode in libpq > src/test/modules/libpq_pipeline/libpq_pipeline.c | 1303 I'm wondering if you meant to leave the "#define DEBUG" line at line 34 in the above file? It seems pretty

pgsql: Allow users of simplehash.h to perform direct deletions

without the code in simplehash.h having to perform an additional hash lookup. Author: David Rowley Reviewed-by: Andres Freund Discussion: https://postgr.es/m/caaphdvqflxxge153wmpsjke5vgost7ez0yd0c7ebxlfmwxs...@mail.gmail.com Branch -- master Details --- https://git.postgresql.org/pg

pgsql: Adjust design of per-worker parallel seqscan data struct

Adjust design of per-worker parallel seqscan data struct The design of the data structures which allow storage of the per-worker memory during parallel seq scans were not ideal. The work done in 56788d215 required an additional data structure to allow workers to remember the range of pages that

pgsql: Cache if PathTarget and RestrictInfos contain volatile functions

at an upcoming patch that must check for volatility during the join search. Repeated volatility checks in that case can become very expensive when the join search contains more than a few relations. Author: David Rowley Discussion: https://postgr.es/m/3795226.1614059...@sss.pgh.pa.us Branch

pgsql: Add missing TidRangeScan readfunc

Add missing TidRangeScan readfunc Mistakenly forgotten in bb437f995 Branch -- master Details --- https://git.postgresql.org/pg/commitdiff/977b2c08535f2a82ba7c310c88420cbbca1772e8 Modified Files -- src/backend/nodes/readfuncs.c | 17 + 1 file changed, 17

pgsql: Add TID Range Scans to support efficient scanning ranges of TIDs

hes the next tuple in the given range. For AMs were scanning ranges of TIDs would not make sense, these functions can be set to NULL in the TableAmRoutine. The query planner won't generate TID Range Scan Paths in that case. Author: Edmund Horner, David Rowley Reviewed-by: David Rowley, Tomas Vondra,

pgsql: Fix hypothetical bug in heap backward scans

. An upcoming patch does use heap_setscanlimits() with backward scans, so this must be fixed before that can go in. Author: David Rowley Discussion: https://postgr.es/m/caaphdvpgc9h0_ovd2ctgbcxcs1n-qdyzsebrnuh+0cwja9c...@mail.gmail.com Backpatch-through: 9.5, all supported versions Branch

pgsql: Fix hypothetical bug in heap backward scans

. An upcoming patch does use heap_setscanlimits() with backward scans, so this must be fixed before that can go in. Author: David Rowley Discussion: https://postgr.es/m/caaphdvpgc9h0_ovd2ctgbcxcs1n-qdyzsebrnuh+0cwja9c...@mail.gmail.com Backpatch-through: 9.5, all supported versions Branch

pgsql: Fix hypothetical bug in heap backward scans

. An upcoming patch does use heap_setscanlimits() with backward scans, so this must be fixed before that can go in. Author: David Rowley Discussion: https://postgr.es/m/caaphdvpgc9h0_ovd2ctgbcxcs1n-qdyzsebrnuh+0cwja9c...@mail.gmail.com Backpatch-through: 9.5, all supported versions Branch

pgsql: Fix hypothetical bug in heap backward scans

. An upcoming patch does use heap_setscanlimits() with backward scans, so this must be fixed before that can go in. Author: David Rowley Discussion: https://postgr.es/m/caaphdvpgc9h0_ovd2ctgbcxcs1n-qdyzsebrnuh+0cwja9c...@mail.gmail.com Backpatch-through: 9.5, all supported versions Branch

pgsql: Fix hypothetical bug in heap backward scans

. An upcoming patch does use heap_setscanlimits() with backward scans, so this must be fixed before that can go in. Author: David Rowley Discussion: https://postgr.es/m/caaphdvpgc9h0_ovd2ctgbcxcs1n-qdyzsebrnuh+0cwja9c...@mail.gmail.com Backpatch-through: 9.5, all supported versions Branch

pgsql: Fix hypothetical bug in heap backward scans

. An upcoming patch does use heap_setscanlimits() with backward scans, so this must be fixed before that can go in. Author: David Rowley Discussion: https://postgr.es/m/caaphdvpgc9h0_ovd2ctgbcxcs1n-qdyzsebrnuh+0cwja9c...@mail.gmail.com Backpatch-through: 9.5, all supported versions Branch

pgsql: Stop gap fix for __attribute__((cold)) compiler bug in MinGW 8.1

Stop gap fix for __attribute__((cold)) compiler bug in MinGW 8.1 The buildfarm animal walleye, running MinGW 8.1 has been having problems ever since 697e1d02f and 913ec71d6 went in. This appears to be a bug in assembler which was fixed in a later version. For now, in order to get that animal

pgsql: Tidy up definitions of pg_attribute_hot and pg_attribute_cold

Tidy up definitions of pg_attribute_hot and pg_attribute_cold 1fa22a43a was a quick fix for portability problem I introduced in 697e1d02f. 1fa22a43a adds a few more cases to the preprocessor logic than I'd have liked. Andres Freund and Dagfinn Ilmari Mannsåker suggested a better way to do this.

pgsql: Fix unportable usage of __has_attribute

Fix unportable usage of __has_attribute This should fix the breakages caused by 697e1d02f, which seems to break the build for GCC version < 5. It seems, according to the GCC manual that __has_attribute is a "special operator" and must be tested without any other conditions in the preprocessor

pgsql: Improve compiler code layout in elog/ereport ERROR calls

n elevel < ERROR or if it cannot be determined to be constant, the original behavior is maintained. Author: David Rowley Reviewed-by: Andres Freund, Peter Eisentraut Discussion: https://postgr.es/m/CAApHDvrVpasrEzLL2er7p9iwZFZ%3DJj6WisePcFeunwfrV0js_A%40mail.gmail.com Branch -- master De

pgsql: Define pg_attribute_cold and pg_attribute_hot macros

Define pg_attribute_cold and pg_attribute_hot macros For compilers supporting __has_attribute and __has_attribute (hot/cold). __has_attribute is supported on gcc >= 5, clang >= 2.9 and icc >= 17. A followup commit will implement some usages of these macros. Author: David Rowley

pgsql: Fix unstable partition_prune regression tests

Fix unstable partition_prune regression tests This was broken recently by a929e17e5. I'd failed to remember that parallel tests should have their EXPLAIN output run through the explain_parallel_append function so that the output is stable when parallel workers fail to start. fairywren was first

Re: pgsql: Allow run-time pruning on nested Append/MergeAppend nodes

On Mon, 2 Nov 2020 at 19:30, Michael Paquier wrote: > fairywen is telling that some of the plans produced in these new tests > are not stable: Thanks. Looking at that now. David

pgsql: Allow run-time pruning on nested Append/MergeAppend nodes

Append just had a single sub-path which was pulled up a level, per 8edd0e794. Author: David Rowley Reviewed-by: Amit Langote Discussion: https://postgr.es/m/flat/CAApHDvqSchs%2BubdybcfFaSPB%2B%2BEA7kqMaoqajtP0GtZvzOOR3g%40mail.gmail.com Branch -- master Details --- https://git.postgresql.org

pgsql: Fix incorrect parameter name in a function header comment

Fix incorrect parameter name in a function header comment Author: Zhijie Hou Discussion: https://postgr.es/m/14cd74ea00204cc8a7ea5d738ac82cd1@G08CNEXMBPEKD05.g08.fujitsu.local Backpatch-through: 12, where the mistake was introduced Branch -- REL_12_STABLE Details ---

pgsql: Fix incorrect parameter name in a function header comment

Fix incorrect parameter name in a function header comment Author: Zhijie Hou Discussion: https://postgr.es/m/14cd74ea00204cc8a7ea5d738ac82cd1@G08CNEXMBPEKD05.g08.fujitsu.local Backpatch-through: 12, where the mistake was introduced Branch -- REL_13_STABLE Details ---

pgsql: Fix incorrect parameter name in a function header comment

Fix incorrect parameter name in a function header comment Author: Zhijie Hou Discussion: https://postgr.es/m/14cd74ea00204cc8a7ea5d738ac82cd1@G08CNEXMBPEKD05.g08.fujitsu.local Backpatch-through: 12, where the mistake was introduced Branch -- master Details ---

pgsql: Optimize a few list_delete_ptr calls

this, but in the general case, none of these lists are likely to be very large, so the lookup was probably never that expensive anyway. However, some of the calls are in fairly hot code paths, e.g process_equivalence(). So any small gains there are useful. Author: Zhijie Hou and David Rowley Discussion: https

pgsql: Relax some asserts in merge join costing code

Relax some asserts in merge join costing code In the planner, it was possible, given an extreme enough case containing a large number of joins for the number of estimated rows to become infinite. This could cause problems in initial_cost_mergejoin() where we perform some calculations based on

pgsql: Relax some asserts in merge join costing code

Relax some asserts in merge join costing code In the planner, it was possible, given an extreme enough case containing a large number of joins for the number of estimated rows to become infinite. This could cause problems in initial_cost_mergejoin() where we perform some calculations based on

pgsql: Relax some asserts in merge join costing code

Relax some asserts in merge join costing code In the planner, it was possible, given an extreme enough case containing a large number of joins for the number of estimated rows to become infinite. This could cause problems in initial_cost_mergejoin() where we perform some calculations based on

pgsql: Relax some asserts in merge join costing code

Relax some asserts in merge join costing code In the planner, it was possible, given an extreme enough case containing a large number of joins for the number of estimated rows to become infinite. This could cause problems in initial_cost_mergejoin() where we perform some calculations based on

pgsql: Relax some asserts in merge join costing code

Relax some asserts in merge join costing code In the planner, it was possible, given an extreme enough case containing a large number of joins for the number of estimated rows to become infinite. This could cause problems in initial_cost_mergejoin() where we perform some calculations based on

pgsql: Relax some asserts in merge join costing code

Relax some asserts in merge join costing code In the planner, it was possible, given an extreme enough case containing a large number of joins for the number of estimated rows to become infinite. This could cause problems in initial_cost_mergejoin() where we perform some calculations based on

pgsql: Prevent overly large and NaN row estimates in relations

Prevent overly large and NaN row estimates in relations Given a query with enough joins, it was possible that the query planner, after multiplying the row estimates with the join selectivity that the estimated number of rows would exceed the limits of the double data type and become infinite. To

pgsql: Fixup some appendStringInfo and appendPQExpBuffer calls

, but further searching by me found significantly more places that deserved the same treatment. Author: Zhijie Hou, David Rowley Discussion: https://postgr.es/m/cb172cf4361e4c7ba7167429070979d4@G08CNEXMBPEKD05.g08.fujitsu.local Branch -- master Details --- https://git.postgresql.org/pg

pgsql: Doc: Improve clarity on partitioned table limitations

Doc: Improve clarity on partitioned table limitations Explicitly mention that primary key constraints are also included in the limitation that the constraint columns must be a superset of the partition key columns. Wording suggestion from Tom Lane. Discussion:

pgsql: Doc: Improve clarity on partitioned table limitations

Doc: Improve clarity on partitioned table limitations Explicitly mention that primary key constraints are also included in the limitation that the constraint columns must be a superset of the partition key columns. Wording suggestion from Tom Lane. Discussion:

pgsql: Doc: Improve clarity on partitioned table limitations

Doc: Improve clarity on partitioned table limitations Explicitly mention that primary key constraints are also included in the limitation that the constraint columns must be a superset of the partition key columns. Wording suggestion from Tom Lane. Discussion:

pgsql: Doc: Improve clarity on partitioned table limitations

Doc: Improve clarity on partitioned table limitations Explicitly mention that primary key constraints are also included in the limitation that the constraint columns must be a superset of the partition key columns. Wording suggestion from Tom Lane. Discussion:

pgsql: Improve pg_list.h's linitial(), lsecond() and co macros

just replace the call within each macro to use list_nth_cell(). For the llast*() case we require a new list_last_cell() inline function to get away from the multiple evaluation hazard that we'd get if we fetched ->length on the macro's parameter. Author: David Rowley Reviewed-by: Tom L

pgsql: Optimize compactify_tuples function

as fast as the original qsort method even when the page just has a few tuples. As the number of tuples becomes larger the new method maintains its performance whereas the original qsort method became much slower when the number of tuples on the page became large. Author: David Rowley Reviewed

pgsql: Fix compiler warning

Fix compiler warning Introduced in 0aa8f7640. MSVC warned about performing 32-bit bit shifting when it appeared like we might like a 64-bit result. We did, but it just so happened that none of the calls to this function could have caused the 32-bit shift to overflow. Here we just cast the

pgsql: Fixup some misusages of bms_num_members()

Fixup some misusages of bms_num_members() It's a bit inefficient to test if a Bitmapset is empty by counting all the members and seeing if that number is zero. It's much better just to use bms_is_empty(). Likewise for checking if there are at least two members, just use bms_membership(), which

pgsql: Fix a few typos in JIT comments and README

Fix a few typos in JIT comments and README Reviewed-by: Abhijit Menon-Sen Reviewed-by: Andres Freund Discussion: https://postgr.es/m/CAApHDvobgmCs6CohqhKTUf7D8vffoZXQTCBTERo9gbOeZmvLTw%40mail.gmail.com Backpatch-through: 11, where JIT was added Branch -- REL_11_STABLE Details ---

pgsql: Fix a few typos in JIT comments and README

Fix a few typos in JIT comments and README Reviewed-by: Abhijit Menon-Sen Reviewed-by: Andres Freund Discussion: https://postgr.es/m/CAApHDvobgmCs6CohqhKTUf7D8vffoZXQTCBTERo9gbOeZmvLTw%40mail.gmail.com Backpatch-through: 11, where JIT was added Branch -- REL_12_STABLE Details ---

pgsql: Fix a few typos in JIT comments and README

Fix a few typos in JIT comments and README Reviewed-by: Abhijit Menon-Sen Reviewed-by: Andres Freund Discussion: https://postgr.es/m/CAApHDvobgmCs6CohqhKTUf7D8vffoZXQTCBTERo9gbOeZmvLTw%40mail.gmail.com Backpatch-through: 11, where JIT was added Branch -- REL_13_STABLE Details ---

pgsql: Fix a few typos in JIT comments and README

Fix a few typos in JIT comments and README Reviewed-by: Abhijit Menon-Sen Reviewed-by: Andres Freund Discussion: https://postgr.es/m/CAApHDvobgmCs6CohqhKTUf7D8vffoZXQTCBTERo9gbOeZmvLTw%40mail.gmail.com Backpatch-through: 11, where JIT was added Branch -- master Details ---

Re: pgsql: Fix race condition in snapshot caching when 2PC is used.

On Wed, 19 Aug 2020 at 12:37, Andres Freund wrote: > > Hi, > > On 2020-08-18 19:55:50 -0400, Tom Lane wrote: > > > I'm inclined to just make ClearTransaction take an exclusive lock - the > > > rest of the 2PC operations are so heavyweight that I can't imagine > > > making a difference. When I

pgsql: Fix bogus EXPLAIN output for Hash Aggregate

Fix bogus EXPLAIN output for Hash Aggregate 9bdb300de modified the EXPLAIN output for Hash Aggregate to show details from parallel workers. However, it neglected to consider that a given parallel worker may not have assisted with the given Hash Aggregate. This can occur when workers fail to start

pgsql: Fix bogus EXPLAIN output for Hash Aggregate

Fix bogus EXPLAIN output for Hash Aggregate 9bdb300de modified the EXPLAIN output for Hash Aggregate to show details from parallel workers. However, it neglected to consider that a given parallel worker may not have assisted with the given Hash Aggregate. This can occur when workers fail to start

pgsql: Use int64 instead of long in incremental sort code

Use int64 instead of long in incremental sort code Windows 64bit has 4-byte long values which is not suitable for tracking disk space usage in the incremental sort code. Let's just make all these fields int64s. Author: James Coleman Discussion:

pgsql: Use int64 instead of long in incremental sort code

Use int64 instead of long in incremental sort code Windows 64bit has 4-byte long values which is not suitable for tracking disk space usage in the incremental sort code. Let's just make all these fields int64s. Author: James Coleman Discussion:

pgsql: Make EXPLAIN ANALYZE of HashAgg more similar to Hash Join

Make EXPLAIN ANALYZE of HashAgg more similar to Hash Join There were various unnecessary differences between Hash Agg's EXPLAIN ANALYZE output and Hash Join's. Here we modify the Hash Agg output so that it's better aligned to Hash Join's. The following changes have been made: 1. Start batches

pgsql: Make EXPLAIN ANALYZE of HashAgg more similar to Hash Join

Make EXPLAIN ANALYZE of HashAgg more similar to Hash Join There were various unnecessary differences between Hash Agg's EXPLAIN ANALYZE output and Hash Join's. Here we modify the Hash Agg output so that it's better aligned to Hash Join's. The following changes have been made: 1. Start batches

pgsql: Doc: Improve documentation for pg_jit_available()

Doc: Improve documentation for pg_jit_available() Per complaint from Scott Ribe. Based on wording suggestion from Tom Lane. Discussion: https://postgr.es/m/1956e806-1468-4417-9a9d-235ae1d5f...@elevated-dev.com Backpatch-through: 11, where pg_jit_available() was added Branch -- master

pgsql: Doc: Improve documentation for pg_jit_available()

Doc: Improve documentation for pg_jit_available() Per complaint from Scott Ribe. Based on wording suggestion from Tom Lane. Discussion: https://postgr.es/m/1956e806-1468-4417-9a9d-235ae1d5f...@elevated-dev.com Backpatch-through: 11, where pg_jit_available() was added Branch --

pgsql: Doc: Improve documentation for pg_jit_available()

Doc: Improve documentation for pg_jit_available() Per complaint from Scott Ribe. Based on wording suggestion from Tom Lane. Discussion: https://postgr.es/m/1956e806-1468-4417-9a9d-235ae1d5f...@elevated-dev.com Backpatch-through: 11, where pg_jit_available() was added Branch --

pgsql: Doc: Improve documentation for pg_jit_available()

Doc: Improve documentation for pg_jit_available() Per complaint from Scott Ribe. Based on wording suggestion from Tom Lane. Discussion: https://postgr.es/m/1956e806-1468-4417-9a9d-235ae1d5f...@elevated-dev.com Backpatch-through: 11, where pg_jit_available() was added Branch --

Re: determine what column(s) form the primary key, in C extention

Hi Alex, On Tue, 28 Jul 2020 at 05:47, alex maslakov wrote: > I was suggested to use `get_primary_key_attnos` from > `src/include/catalog/pg_constraint.h` > > extern Bitmapset *get_primary_key_attnos(Oid relid, bool deferrableOk) > > > It returns *Bitstamp. And it's got "nwords" and "words[]".

pgsql: Allocate consecutive blocks during parallel seqscans

ems, so we may need to later provide users with some ability to get something closer to the old behavior. For now, let's leave that until we see that it's really required. Author: Thomas Munro, David Rowley Reviewed-by: Ranier Vilela, Soumyadeep Chakraborty, Robert Haas Reviewed-by: Amit Kapila, Ki

pgsql: Add comment to explain an unused function parameter

Add comment to explain an unused function parameter Removing the unused 'miinfo' parameter has been raised a couple of times now. It was decided in the 2nd discussion below that we're going to leave it alone. It seems like it might be useful to add a comment to mention this fact so that nobody

pgsql: Fix timing issue with ALTER TABLE's validate constraint

Fix timing issue with ALTER TABLE's validate constraint An ALTER TABLE to validate a foreign key in which another subcommand already caused a pending table rewrite could fail due to ALTER TABLE attempting to validate the foreign key before the actual table rewrite takes place. This situation

pgsql: Fix timing issue with ALTER TABLE's validate constraint

Fix timing issue with ALTER TABLE's validate constraint An ALTER TABLE to validate a foreign key in which another subcommand already caused a pending table rewrite could fail due to ALTER TABLE attempting to validate the foreign key before the actual table rewrite takes place. This situation

pgsql: Fix timing issue with ALTER TABLE's validate constraint

Fix timing issue with ALTER TABLE's validate constraint An ALTER TABLE to validate a foreign key in which another subcommand already caused a pending table rewrite could fail due to ALTER TABLE attempting to validate the foreign key before the actual table rewrite takes place. This situation

pgsql: Fix timing issue with ALTER TABLE's validate constraint

Fix timing issue with ALTER TABLE's validate constraint An ALTER TABLE to validate a foreign key in which another subcommand already caused a pending table rewrite could fail due to ALTER TABLE attempting to validate the foreign key before the actual table rewrite takes place. This situation

pgsql: Fix timing issue with ALTER TABLE's validate constraint

Fix timing issue with ALTER TABLE's validate constraint An ALTER TABLE to validate a foreign key in which another subcommand already caused a pending table rewrite could fail due to ALTER TABLE attempting to validate the foreign key before the actual table rewrite takes place. This situation

pgsql: Fix timing issue with ALTER TABLE's validate constraint

Fix timing issue with ALTER TABLE's validate constraint An ALTER TABLE to validate a foreign key in which another subcommand already caused a pending table rewrite could fail due to ALTER TABLE attempting to validate the foreign key before the actual table rewrite takes place. This situation

pgsql: Fix timing issue with ALTER TABLE's validate constraint

Fix timing issue with ALTER TABLE's validate constraint An ALTER TABLE to validate a foreign key in which another subcommand already caused a pending table rewrite could fail due to ALTER TABLE attempting to validate the foreign key before the actual table rewrite takes place. This situation

pgsql: Fix whitespace in HashAgg EXPLAIN ANALYZE

Fix whitespace in HashAgg EXPLAIN ANALYZE The Sort node does not put a space between the number of kilobytes and the "kB" of memory or disk space used, but HashAgg does. Here we align HashAgg to do the same as Sort. Sort has been displaying this information for longer than HashAgg, so it makes

pgsql: Fix whitespace in HashAgg EXPLAIN ANALYZE

Fix whitespace in HashAgg EXPLAIN ANALYZE The Sort node does not put a space between the number of kilobytes and the "kB" of memory or disk space used, but HashAgg does. Here we align HashAgg to do the same as Sort. Sort has been displaying this information for longer than HashAgg, so it makes

pgsql: Further adjustments to Hashagg EXPLAIN ANALYZE output

Further adjustments to Hashagg EXPLAIN ANALYZE output The "Disk Usage" and "HashAgg Batches" properties in the EXPLAIN ANALYZE output for HashAgg were previously only shown if the number of batches was greater than 0. Here we change this so that these properties are always shown for EXPLAIN

pgsql: Further adjustments to Hashagg EXPLAIN ANALYZE output

Further adjustments to Hashagg EXPLAIN ANALYZE output The "Disk Usage" and "HashAgg Batches" properties in the EXPLAIN ANALYZE output for HashAgg were previously only shown if the number of batches was greater than 0. Here we change this so that these properties are always shown for EXPLAIN

pgsql: Fix EXPLAIN ANALYZE for parallel HashAgg plans

Fix EXPLAIN ANALYZE for parallel HashAgg plans Since 1f39bce02, HashAgg nodes have had the ability to spill to disk when memory consumption exceeds work_mem. That commit added new properties to EXPLAIN ANALYZE to show the maximum memory usage and disk usage, however, it didn't quite go as far as

pgsql: Fix EXPLAIN ANALYZE for parallel HashAgg plans

Fix EXPLAIN ANALYZE for parallel HashAgg plans Since 1f39bce02, HashAgg nodes have had the ability to spill to disk when memory consumption exceeds work_mem. That commit added new properties to EXPLAIN ANALYZE to show the maximum memory usage and disk usage, however, it didn't quite go as far as

pgsql: Have pg_itoa, pg_ltoa and pg_lltoa return the length of the stri

Have pg_itoa, pg_ltoa and pg_lltoa return the length of the string Core by no means makes excessive use of these functions, but quite a large number of those usages do require the caller to call strlen() on the returned string. This is quite wasteful since these functions do already have a good

pgsql: Add missing extern keyword for a couple of numutils functions

Add missing extern keyword for a couple of numutils functions In passing, also remove a few surplus empty lines from pg_ltoa and pg_ulltoa_n in numutils.c Reported-by: Andrew Gierth Discussion: https://postgr.es/m/87y2ou3xuh@news-spur.riddles.org.uk Backpatch-through: 13, where these changes

pgsql: Add missing extern keyword for a couple of numutils functions

Add missing extern keyword for a couple of numutils functions In passing, also remove a few surplus empty lines from pg_ltoa and pg_ulltoa_n in numutils.c Reported-by: Andrew Gierth Discussion: https://postgr.es/m/87y2ou3xuh@news-spur.riddles.org.uk Backpatch-through: 13, where these changes

pgsql: Fix invalid function references in a few comments

Fix invalid function references in a few comments These appear to have been forgotten when the functions were renamed in 1fd687a03. Backpatch-through: 13, where the functions were renamed Branch -- REL_13_STABLE Details ---

pgsql: Fix invalid function references in a few comments

Fix invalid function references in a few comments These appear to have been forgotten when the functions were renamed in 1fd687a03. Backpatch-through: 13, where the functions were renamed Branch -- master Details ---

pgsql: Remove bogus Assert in foreign key cloning code

Remove bogus Assert in foreign key cloning code This Assert was trying to ensure that the number of columns in the foreign key being cloned was the same number of attributes in the parentRel.  Of course, it's perfectly valid to have columns in the table which are not part of the foreign key

pgsql: Fix possible crash with GENERATED ALWAYS columns

Fix possible crash with GENERATED ALWAYS columns In some corner cases, this could also lead to corrupted values being included in the tuple. Users who are concerned that they are affected by this should first upgrade and then perform a base backup of their database and restore onto an off-line

pgsql: Fix possible crash with GENERATED ALWAYS columns

Fix possible crash with GENERATED ALWAYS columns In some corner cases, this could also lead to corrupted values being included in the tuple. Users who are concerned that they are affected by this should first upgrade and then perform a base backup of their database and restore onto an off-line

pgsql: Remove unneeded constraint dependency tracking

Remove unneeded constraint dependency tracking It was previously thought that remove_useless_groupby_columns() needed to keep track of which constraints the generated plan depended upon, however, this is unnecessary. The confusion likely arose regarding this because of

pgsql: Modify additional power 2 calculations to use new helper functio

Modify additional power 2 calculations to use new helper functions 2nd pass of modifying various places which obtain the next power of 2 of a number and make them use the new functions added in f0705bb62. In passing, also modify num_combinations(). This can be implemented using simple

pgsql: Modify various power 2 calculations to use new helper functions

Modify various power 2 calculations to use new helper functions First pass of modifying various places that obtain the next power of 2 of a number and make them use the new functions added in pg_bitutils.h instead. This also removes the _hash_log2() function. There are no longer any callers in

pgsql: Add functions to calculate the next power of 2

Add functions to calculate the next power of 2 There are many areas in the code where we need to determine the next highest power of 2 of a given number. We tend to always do that in an ad-hoc way each time, generally with some tight for loop which performs a bitshift left once per loop and goes

pgsql: Attempt to stabilize partitionwise_aggregate test

Attempt to stabilize partitionwise_aggregate test In b07642dbc, we added code to trigger autovacuums based on the number of INSERTs into a table. This seems to have cause some destabilization of the regression tests. Likely this is due to an autovacuum triggering mid-test and (per theory from Tom

Re: pgsql: Attempt to fix unstable regression tests, take 2

On Wed, 1 Apr 2020 at 13:00, Tom Lane wrote: > > David Rowley writes: > > On Tue, 31 Mar 2020 at 15:55, Tom Lane wrote: > >> Now this *IS* autovacuum interference, but it's hardly autovacuum's fault: > >> the test script is supposing that autovac won't come i

Re: pgsql: Attempt to fix unstable regression tests, take 2

On Tue, 31 Mar 2020 at 15:55, Tom Lane wrote: > I've been trying to reproduce this by dint of running just the stats_ext > script, over and over in a loop. I've not had any success on fast > machines, but on a slow one (florican's host) I got this after a few > hundred iterations: I've had a 13

pgsql: Attempt to fix unstable regression tests, take 2

Attempt to fix unstable regression tests, take 2 Following up on 2dc16efed, petalura has suffered some additional failures in stats_ext which again appear to be around the timing of an autovacuum during the test, causing instability in the row estimates. Again, let's fix this by explicitly

pgsql: Attempt to fix unstable regression tests

Attempt to fix unstable regression tests b07642dbc added code to trigger autovacuums based on the number of inserts into a table. This seems to have caused some regression test results to destabilize. I suspect this is due to autovacuum triggering a vacuum sometime after the test's ANALYZE run

pgsql: Trigger autovacuum based on number of INSERTs

Trigger autovacuum based on number of INSERTs Traditionally autovacuum has only ever invoked a worker based on the estimated number of dead tuples in a table and for anti-wraparound purposes. For the latter, with certain classes of tables such as insert-only tables, anti-wraparound vacuums could

pgsql: Use appendBinaryStringInfo in more places where the length is kn

Use appendBinaryStringInfo in more places where the length is known When we already know the length that we're going to append, then it makes sense to use appendBinaryStringInfo instead of appendStringInfoString so that the append can be performed with a simple memcpy() using a known length

pgsql: Make better use of the new List implementation in a couple of pl

Make better use of the new List implementation in a couple of places In nodeAppend.c and nodeMergeAppend.c there were some foreach loops which looped over the list of subplans and only performed any work if the subplan index was found in a Bitmapset. With the old linked list implementation of

pgsql: Adjust overly strict Assert

Adjust overly strict Assert 3373c7155 changed how we determine EquivalenceClasses for relations and added an Assert to ensure all relations mentioned in each EC's ec_relids was a RELOPT_BASEREL. However, the join removal code may remove a LEFT JOIN and since it does not clean up EC members

pgsql: Speed up finding EquivalenceClasses for a given set of rels

condition which was introduced by 100340e2d. However, we're speeding up much more than just that here. Author: David Rowley, Tom Lane Reviewed-by: Tom Lane, Tomas Vondra Discussion: https://postgr.es/m/6970.1545327...@sss.pgh.pa.us Branch -- master Details --- https://git.postgresql.org/pg

pgsql: Fix RANGE partition pruning with multiple boolean partition keys

Fix RANGE partition pruning with multiple boolean partition keys match_clause_to_partition_key incorrectly would return PARTCLAUSE_UNSUPPORTED if a bool qual could not be matched to the current partition key. This was a problem, as it causes the calling function to discard the qual and not try

pgsql: Fix RANGE partition pruning with multiple boolean partition keys

Fix RANGE partition pruning with multiple boolean partition keys match_clause_to_partition_key incorrectly would return PARTCLAUSE_UNSUPPORTED if a bool qual could not be matched to the current partition key. This was a problem, as it causes the calling function to discard the qual and not try

pgsql: Fix RANGE partition pruning with multiple boolean partition keys

Fix RANGE partition pruning with multiple boolean partition keys match_clause_to_partition_key incorrectly would return PARTCLAUSE_UNSUPPORTED if a bool qual could not be matched to the current partition key. This was a problem, as it causes the calling function to discard the qual and not try

<    2   3   4   5   6   7   8   >