pgsql: nbtree: Rename nbtinsert.c variables for consistency.
nbtree: Rename nbtinsert.c variables for consistency. Stop naming special area/opaque pointer variables 'lpageop' in contexts where it doesn't make sense. This is a holdover from a time when logic that performs tasks that are now spread across _bt_insertonpg(), _bt_findinsertloc(), and _bt_split() was more centralized. 'lpageop' denotes "left page", which doesn't make sense outside of contexts in which there isn't also a right page. Also acquire page flag variables up front within _bt_insertonpg(). This makes it closer to _bt_split() following refactoring commit bc3087b626d. This allows the page split and retail insert paths to both make use of the same variables. Branch -- master Details --- https://git.postgresql.org/pg/commitdiff/a034f8b60c6e9afd75f42dc420a76cb9d3875fcb Modified Files -- src/backend/access/nbtree/nbtinsert.c | 121 +- 1 file changed, 62 insertions(+), 59 deletions(-)
pgsql: indexcmds.c: reorder function prototypes
indexcmds.c: reorder function prototypes ... out of an overabundance of neatnikism, perhaps. Branch -- master Details --- https://git.postgresql.org/pg/commitdiff/7684b6fbed3a0770a0d8fdcbb5cf8b61394de691 Modified Files -- src/backend/commands/indexcmds.c | 7 +++ 1 file changed, 3 insertions(+), 4 deletions(-)
pgsql: Deprecate nbtree's BTP_HAS_GARBAGE flag.
Deprecate nbtree's BTP_HAS_GARBAGE flag. Streamline handling of the various strategies that we have to avoid a page split in nbtinsert.c. When it looks like a leaf page is about to overflow, we now perform deleting LP_DEAD items and deduplication in one central place. This greatly simplifies _bt_findinsertloc(). This has an independently useful consequence: nbtree no longer relies on the BTP_HAS_GARBAGE page level flag/hint for anything important. We still set and unset the flag in the same way as before, but it's no longer treated as a gating condition when considering if we should check for already-set LP_DEAD bits. This happens at the point where the page looks like it might have to be split anyway, so simply checking the LP_DEAD bits in passing is practically free. This avoids missing LP_DEAD bits just because the page-level hint is unset, which is probably reasonably common (e.g. it happens when VACUUM unsets the page-level flag without actually removing index tuples whose LP_DEAD-bit was set recently, after the VACUUM operation began but before it reached the leaf page in question). Note that this isn't a big behavioral change compared to PostgreSQL 13. We were already checking for set LP_DEAD bits regardless of whether the BTP_HAS_GARBAGE page level flag was set before we considered doing a deduplication pass. This commit only goes slightly further by doing the same check for all indexes, even indexes where deduplication won't be performed. We don't completely remove the BTP_HAS_GARBAGE flag. We still rely on it as a gating condition with pg_upgrade'd indexes from before B-tree version 4/PostgreSQL 12. That makes sense because we sometimes have to make a choice among pages full of duplicates when inserting a tuple with pre version 4 indexes. It probably still pays to avoid accessing the line pointer array of a page there, since it won't yet be clear whether we'll insert on to the page in question at all, let alone split it as a result. Author: Peter Geoghegan Reviewed-By: Victor Yegorov Discussion: https://postgr.es/m/CAH2-Wz%3DYpc1PDdk8OVJDChGJBjT06%3DA0Mbv9HyTLCsOknGcUFg%40mail.gmail.com Branch -- master Details --- https://git.postgresql.org/pg/commitdiff/cf2acaf4dcb5e20204dcec4d698cb4478af533e7 Modified Files -- src/backend/access/nbtree/nbtdedup.c | 76 -- src/backend/access/nbtree/nbtinsert.c | 142 +++--- src/backend/access/nbtree/nbtpage.c | 33 src/backend/access/nbtree/nbtutils.c | 3 +- src/backend/access/nbtree/nbtxlog.c | 3 +- src/include/access/nbtree.h | 8 +- 6 files changed, 135 insertions(+), 130 deletions(-)
pgsql: Add tab completion for CREATE [OR REPLACE] TRIGGER in psql
Add tab completion for CREATE [OR REPLACE] TRIGGER in psql 92bf7e2 has added support for this grammar. Author: Noriyoshi Shinoda Discussion: https://postgr.es/m/tu4pr8401mb115244623cf4724dca0d507fee...@tu4pr8401mb1152.namprd84.prod.outlook.com Branch -- master Details --- https://git.postgresql.org/pg/commitdiff/bf0aa7c4b83bcf3116c5a3c191bbc677ab3beb59 Modified Files -- src/bin/psql/tab-complete.c | 105 1 file changed, 76 insertions(+), 29 deletions(-)
pgsql: Add more tests for hashing and hash-based plans
Add more tests for hashing and hash-based plans - Test hashing of an array of a non-hashable element type. - Test UNION [DISTINCT] with hash- and sort-based plans. (Previously, only INTERSECT and EXCEPT where tested there.) - Test UNION [DISTINCT] with a non-hashable column type. This currently reverts to a sort-based plan even if enable_hashagg is on. - Test UNION/INTERSECT/EXCEPT hash- and sort-based plans with arrays as column types. Also test an array with a non-hashable element type. - Test UNION/INTERSECT/EXCEPT similarly with row types as column types. Currently, this uses only sort-based plans because there is no hashing support for row types. - Add a test case that shows that recursive queries using UNION [DISTINCT] require hashable column types. - Add a currently failing test that uses UNION DISTINCT in a cycle-detection use case using row types as column types. Discussion: https://www.postgresql.org/message-id/flat/38eccd35-4e2d-6767-1b3c-dada1eac3124%402ndquadrant.com Branch -- master Details --- https://git.postgresql.org/pg/commitdiff/6dd8b00807871bfd0c3ce8e18fd1f6ba1a71fbf9 Modified Files -- src/test/regress/expected/hash_func.out | 7 + src/test/regress/expected/union.out | 357 +++- src/test/regress/expected/with.out | 20 ++ src/test/regress/sql/hash_func.sql | 6 + src/test/regress/sql/union.sql | 92 +++- src/test/regress/sql/with.sql | 18 ++ 6 files changed, 498 insertions(+), 2 deletions(-)
