pgsql: Update ICU C++ API symbols

Update ICU C++ API symbols Recent ICU versions have added U_SHOW_CPLUSPLUS_HEADER_API, and we need to set this to zero as well to hide the ICU C++ APIs from pg_locale.h Per discussion, we want cpluspluscheck to work cleanly in backbranches, so backpatch both this and its predecessor commit ed26c4

pgsql: Update ICU C++ API symbols

Update ICU C++ API symbols Recent ICU versions have added U_SHOW_CPLUSPLUS_HEADER_API, and we need to set this to zero as well to hide the ICU C++ APIs from pg_locale.h Per discussion, we want cpluspluscheck to work cleanly in backbranches, so backpatch both this and its predecessor commit ed26c4

pgsql: Update ICU C++ API symbols

Update ICU C++ API symbols Recent ICU versions have added U_SHOW_CPLUSPLUS_HEADER_API, and we need to set this to zero as well to hide the ICU C++ APIs from pg_locale.h Per discussion, we want cpluspluscheck to work cleanly in backbranches, so backpatch both this and its predecessor commit ed26c4

pgsql: Update ICU C++ API symbols

Update ICU C++ API symbols Recent ICU versions have added U_SHOW_CPLUSPLUS_HEADER_API, and we need to set this to zero as well to hide the ICU C++ APIs from pg_locale.h Per discussion, we want cpluspluscheck to work cleanly in backbranches, so backpatch both this and its predecessor commit ed26c4

pgsql: Update ICU C++ API symbols

Update ICU C++ API symbols Recent ICU versions have added U_SHOW_CPLUSPLUS_HEADER_API, and we need to set this to zero as well to hide the ICU C++ APIs from pg_locale.h Per discussion, we want cpluspluscheck to work cleanly in backbranches, so backpatch both this and its predecessor commit ed26c4

pgsql: Update ICU C++ API symbols

Update ICU C++ API symbols Recent ICU versions have added U_SHOW_CPLUSPLUS_HEADER_API, and we need to set this to zero as well to hide the ICU C++ APIs from pg_locale.h Per discussion, we want cpluspluscheck to work cleanly in backbranches, so backpatch both this and its predecessor commit ed26c4

pgsql: Update ICU C++ API symbols

Update ICU C++ API symbols Recent ICU versions have added U_SHOW_CPLUSPLUS_HEADER_API, and we need to set this to zero as well to hide the ICU C++ APIs from pg_locale.h Per discussion, we want cpluspluscheck to work cleanly in backbranches, so backpatch both this and its predecessor commit ed26c4

pgsql: Hide ICU C++ APIs from pg_locale.h

Hide ICU C++ APIs from pg_locale.h The cpluspluscheck script wraps our headers in `extern "C"`. This disables name mangling, which is necessary for the C++ templates in system ICU headers. cpluspluscheck thus fails when the build is configured with ICU (the default). CI worked around this by disab

pgsql: Remove implicit cast from 'void *'

Remove implicit cast from 'void *' Commit e2809e3a101 added code to a header which assigns a pointer to void to a pointer to unsigned char. This causes build errors for extensions written in C++. Fix by adding an explicit cast. Reviewed-by: Tom Lane Discussion: https://postgr.es/m/CANWCAZaCq9AH

pgsql: Remove implicit cast from 'void *'

Remove implicit cast from 'void *' Commit e2809e3a101 added code to a header which assigns a pointer to void to a pointer to unsigned char. This causes build errors for extensions written in C++. Fix by adding an explicit cast. Reviewed-by: Tom Lane Discussion: https://postgr.es/m/CANWCAZaCq9AH

pgsql: Properly fix AVX-512 CRC calculation bug

Properly fix AVX-512 CRC calculation bug The problem that led to the workaround in f83f14881c7 was not in fact a compiler bug, but a failure to zero the upper bits of the vector register containing the initial scalar CRC value. Fix that and revert the workaround. Diagnosed-by: Nathan Bossart Dia

pgsql: Workaround code generation bug in clang

Workaround code generation bug in clang At optimization level -O0, builds on recent clang fail to produce the correct CRC32C with our AVX-512 implementation. For now, just disable the runtime check for clang at -O0. When this is fixed upstream and we know the extent of the breakage, we can adjust

Re: clang-tidy complaints

not the "targeting SSE 4.2" stanza.) -- John Naylor Amazon Web Services

pgsql: Match parameter in new function to earlier equivalents

Match parameter in new function to earlier equivalents Oversight in commit 3c6e8c123. Branch -- master Details --- https://git.postgresql.org/pg/commitdiff/27757677ca4da566ff21f65c58a008818afb5b06 Modified Files -- src/include/port/pg_crc32c.h | 2 +- src/port/pg_crc32c_sse42

pgsql: Compute CRC32C using AVX-512 instructions where available

Compute CRC32C using AVX-512 instructions where available The previous implementation of CRC32C on x86 relied on the native CRC32 instruction from the SSE 4.2 extension, which operates on up to 8 bytes at a time. We can get a substantial speedup by using carryless multiplication on SIMD registers,

pgsql: Inline CRC computation for small fixed-length input on x86

Inline CRC computation for small fixed-length input on x86 pg_crc32c.h now has a simplified copy of the loop in pg_crc32c_sse42.c suitable for inlining where possible. This may slightly reduce contention for the WAL insertion lock, but that hasn't been tested. The motivation for this change is av

Re: pgsql: Inline CRC computation for small fixed-length input on x86

On Tue, Apr 1, 2025 at 1:58 AM Todd Cook wrote: > > On 3/31/25, 7:17 AM, "John Naylor" <mailto:johncnaylo...@gmail.com>> wrote: > > A possible workaround would be add a normally-superfluous > > "pg_attribute_target("sse4.2")" to th

pgsql: Use function attributes for SSE 4.2 even when targeting that ext

Use function attributes for SSE 4.2 even when targeting that extension On Red Hat 9 systems (or similar), the packaged gcc targets x86-64-v2, but clang does not. This has caused build failures in the wake of commit e2809e3a1 when building --with-llvm. The most expedient fix is to use the same fun

Re: pgsql: Inline CRC computation for small fixed-length input on x86

ll up in the air, and we have confirmation that the attributes will get the buildfarm green again, I'll go do that now. -- John Naylor Amazon Web Services

Re: pgsql: Inline CRC computation for small fixed-length input on x86

On Mon, Mar 31, 2025 at 3:07 PM John Naylor wrote: > > On Mon, Mar 31, 2025 at 2:18 PM John Naylor wrote: > > > Hmm, skimmer doesn't like this, and it's one of the animals that > > builds with -msse4.2: > > > > https://buildfarm.postgresql.org/cgi-bin

Re: pgsql: Inline CRC computation for small fixed-length input on x86

ang version 18.1.8 (RESF 18.1.8-3.el9) Must be related. Is there anything special about this build? CFLAGS? Are you building with autoconf or meson? Could you please share the CRC section from output of configure (or meson)? -- John Naylor Amazon Web Services

Re: pgsql: Inline CRC computation for small fixed-length input on x86

On Mon, Mar 31, 2025 at 2:18 PM John Naylor wrote: > Hmm, skimmer doesn't like this, and it's one of the animals that > builds with -msse4.2: > > https://buildfarm.postgresql.org/cgi-bin/show_stage_log.pl?nm=skimmer&dt=2025-03-31%2007%3A00%3A27&stg=configu

Re: pgsql: Inline CRC computation for small fixed-length input on x86

On Mon, Mar 31, 2025 at 1:28 PM John Naylor wrote: > > Inline CRC computation for small fixed-length input on x86 Hmm, skimmer doesn't like this, and it's one of the animals that builds with -msse4.2: https://buildfarm.postgresql.org/cgi-bin/show_stage_log.pl?nm=skimmer&dt=

pgsql: Doc: correct aggressive vacuum threshold for multixact members s

Doc: correct aggressive vacuum threshold for multixact members storage The threshold is two billion members, which was interpreted as 2GB in the documentation. Fix to reflect that each member takes up five bytes, which translates to about 10GB. This is not exact, because of page boundaries. While

Re: pgsql: vacuumdb: Add option for analyzing only relations missing stats.

On Fri, Mar 7, 2025 at 10:29 AM John Naylor wrote: > > vacuumdb: Add option for analyzing only relations missing stats. My apologies, I didn't realize I had applied this to master branch when reviewing it, will revert. -- John Naylor Amazon Web Services

pgsql: vacuumdb: Add option for analyzing only relations missing stats.

vacuumdb: Add option for analyzing only relations missing stats. This commit adds a new --missing-only option that can be used in conjunction with --analyze-only and --analyze-in-stages. When this option is specified, vacuumdb will generate ANALYZE commands for a relation if it is missing any sta

pgsql: Revert "vacuumdb: Add option for analyzing only relations missin

Revert "vacuumdb: Add option for analyzing only relations missing stats." This reverts commit 5f8eb25706b62923c53172e453c8a4dedd877a3d, which in my branch by mistake. Branch -- master Details --- https://git.postgresql.org/pg/commitdiff/19e57f4f78e4354d9a21c284868373d28bb0d368 Modified

pgsql: Doc: correct aggressive vacuum threshold for multixact members s

Doc: correct aggressive vacuum threshold for multixact members storage The threshold is two billion members, which was interpreted as 2GB in the documentation. Fix to reflect that each member takes up five bytes, which translates to about 10GB. This is not exact, because of page boundaries. While

pgsql: Doc: correct aggressive vacuum threshold for multixact members s

Doc: correct aggressive vacuum threshold for multixact members storage The threshold is two billion members, which was interpreted as 2GB in the documentation. Fix to reflect that each member takes up five bytes, which translates to about 10GB. This is not exact, because of page boundaries. While

pgsql: Doc: correct aggressive vacuum threshold for multixact members s

Doc: correct aggressive vacuum threshold for multixact members storage The threshold is two billion members, which was interpreted as 2GB in the documentation. Fix to reflect that each member takes up five bytes, which translates to about 10GB. This is not exact, because of page boundaries. While

pgsql: Doc: correct aggressive vacuum threshold for multixact members s

Doc: correct aggressive vacuum threshold for multixact members storage The threshold is two billion members, which was interpreted as 2GB in the documentation. Fix to reflect that each member takes up five bytes, which translates to about 10GB. This is not exact, because of page boundaries. While

pgsql: Silence warning in older versions of Valgrind

Silence warning in older versions of Valgrind Due to misunderstanding on my part, commit 235328ee4 did not go far enough to silence older versions of Valgrind. For those, it was the bit scan that was problematic, not the subsequent bit-masking operation. To fix, use the unaligned path for the trai

pgsql: Silence warning in older versions of Valgrind

Silence warning in older versions of Valgrind Due to misunderstanding on my part, commit 235328ee4 did not go far enough to silence older versions of Valgrind. For those, it was the bit scan that was problematic, not the subsequent bit-masking operation. To fix, use the unaligned path for the trai

pgsql: Specialize intarray sorting

Specialize intarray sorting There is at least one report in the field of storing millions of integers in arrays, so it seems like a good time to specialize intarray's qsort function. In doing so, streamline the comparators: Previously there were three, two for each direction for sorting and one pa

pgsql: Doc: Fix punctuation errors

Doc: Fix punctuation errors Author: 斉藤登 Reviewed-by: David G. Johnston Discussion: https://postgr.es/m/caam3qnl6i-bsu5rb2+kihljmcoxiqeipmbvej7f1cguzzmo...@mail.gmail.com Backpatch-through: 13 Branch -- REL_17_STABLE Details --- https://git.postgresql.org/pg/commitdiff/fa761d9c71375ec4

pgsql: Doc: Fix punctuation errors

Doc: Fix punctuation errors Author: 斉藤登 Reviewed-by: David G. Johnston Discussion: https://postgr.es/m/caam3qnl6i-bsu5rb2+kihljmcoxiqeipmbvej7f1cguzzmo...@mail.gmail.com Backpatch-through: 13 Branch -- master Details --- https://git.postgresql.org/pg/commitdiff/0bc34ad69204dded9cd06d0

pgsql: Doc: Fix punctuation errors

Doc: Fix punctuation errors Author: 斉藤登 Reviewed-by: David G. Johnston Discussion: https://postgr.es/m/caam3qnl6i-bsu5rb2+kihljmcoxiqeipmbvej7f1cguzzmo...@mail.gmail.com Backpatch-through: 13 Branch -- REL_16_STABLE Details --- https://git.postgresql.org/pg/commitdiff/d29bf192e5498418

pgsql: Doc: Fix punctuation errors

Doc: Fix punctuation errors Author: 斉藤登 Reviewed-by: David G. Johnston Discussion: https://postgr.es/m/caam3qnl6i-bsu5rb2+kihljmcoxiqeipmbvej7f1cguzzmo...@mail.gmail.com Backpatch-through: 13 Branch -- REL_13_STABLE Details --- https://git.postgresql.org/pg/commitdiff/412047f19fcb9785

pgsql: Doc: Fix punctuation errors

Doc: Fix punctuation errors Author: 斉藤登 Reviewed-by: David G. Johnston Discussion: https://postgr.es/m/caam3qnl6i-bsu5rb2+kihljmcoxiqeipmbvej7f1cguzzmo...@mail.gmail.com Backpatch-through: 13 Branch -- REL_14_STABLE Details --- https://git.postgresql.org/pg/commitdiff/80b23bf5b858d54c

pgsql: Doc: Fix punctuation errors

Doc: Fix punctuation errors Author: 斉藤登 Reviewed-by: David G. Johnston Discussion: https://postgr.es/m/caam3qnl6i-bsu5rb2+kihljmcoxiqeipmbvej7f1cguzzmo...@mail.gmail.com Backpatch-through: 13 Branch -- REL_15_STABLE Details --- https://git.postgresql.org/pg/commitdiff/9efd78ef6b091904

pgsql: Fix grammatical typos around possessive "its"

Fix grammatical typos around possessive "its" Some places spelled it "it's", which is short for "it is". In passing, fix a couple other nearby grammatical errors. Author: Jacob Brazeal Discussion: https://postgr.es/m/CA+COZaAO8g1KJCV0T48=ckjmjannftglwoatz+2ach40c2n...@mail.gmail.com Branch ---

pgsql: Revert "Speed up tail processing when hashing aligned C strings,

Revert "Speed up tail processing when hashing aligned C strings, take two" This reverts commit a365d9e2e8c1ead27203a4431211098292777d3b. Older versions of Valgrind raise an error, so go back to the bytewise loop for the final word in the input. Reported-by: Anton A. Melnikov Discussion: https:

pgsql: Revert "Speed up tail processing when hashing aligned C strings,

Revert "Speed up tail processing when hashing aligned C strings, take two" This reverts commit a365d9e2e8c1ead27203a4431211098292777d3b. Older versions of Valgrind raise an error, so go back to the bytewise loop for the final word in the input. Reported-by: Anton A. Melnikov Discussion: https:

pgsql: Speed up hex_encode with bytewise lookup

Speed up hex_encode with bytewise lookup Previously, hex_encode looked up each nibble of the input separately. We now use a larger lookup table containing the two-byte encoding of every possible input byte, resulting in a 1/3 reduction in encoding time. Reviewed by Tom Lane, Michael Paquier, Nath

pgsql: Always use the caller-provided context for radix tree leaves

Always use the caller-provided context for radix tree leaves Previously, it would not have worked for a caller to pass a slab context, since it would have been used for other things which likely had incompatible size. In an attempt to be helpful and avoid possible space wastage due to aset's power

pgsql: Get rid of radix tree's general purpose memory context

Get rid of radix tree's general purpose memory context Previously, this was notionally used only for the entry point of the tree and as a convenient parent for other contexts. For shared memory, the creator previously allocated the entry point in this context, but attaching backends didn't have a

pgsql: Use caller's memory context for radix tree iteration state

Use caller's memory context for radix tree iteration state Typically only one iterator is present at any time, so it's overkill to devote an entire context for this. Get rid of it and use the caller's context. This is tidy-up work, so no backpatch in this form. However, a hypothetical extension t

pgsql: Fix typo

Fix typo Ryo Kanbayashi Discussion: https://postgr.es/m/CANOn0ExEQiPVrzkjULkENVac_n4Lknm6dxsU69MSncQap0kJVA%40mail.gmail.com Branch -- master Details --- https://git.postgresql.org/pg/commitdiff/c72ca3ddec15b73d9f9dc3e21b8db5d958b0dad7 Modified Files -- src/backend/optimiz

pgsql: Fix use-after-free in parallel_vacuum_reset_dead_items

Fix use-after-free in parallel_vacuum_reset_dead_items parallel_vacuum_reset_dead_items used a local variable to hold a pointer from the passed vacrel, purely as a shorthand. This pointer was later freed and a new allocation was made and stored to the struct. Then the local pointer was mistakenly

pgsql: Fix use-after-free in parallel_vacuum_reset_dead_items

Fix use-after-free in parallel_vacuum_reset_dead_items parallel_vacuum_reset_dead_items used a local variable to hold a pointer from the passed vacrel, purely as a shorthand. This pointer was later freed and a new allocation was made and stored to the struct. Then the local pointer was mistakenly

pgsql: Document limit on the number of out-of-line values per table

Document limit on the number of out-of-line values per table Document the hard limit stemming from the size of an OID, and also mention the perfomance impact that occurs before the hard limit is reached. Jakub Wartak and Robert Haas Backpatch to all supported versions Discussion: https://postgr

pgsql: Document limit on the number of out-of-line values per table

Document limit on the number of out-of-line values per table Document the hard limit stemming from the size of an OID, and also mention the perfomance impact that occurs before the hard limit is reached. Jakub Wartak and Robert Haas Backpatch to all supported versions Discussion: https://postgr

pgsql: Document limit on the number of out-of-line values per table

Document limit on the number of out-of-line values per table Document the hard limit stemming from the size of an OID, and also mention the perfomance impact that occurs before the hard limit is reached. Jakub Wartak and Robert Haas Backpatch to all supported versions Discussion: https://postgr

pgsql: Document limit on the number of out-of-line values per table

Document limit on the number of out-of-line values per table Document the hard limit stemming from the size of an OID, and also mention the perfomance impact that occurs before the hard limit is reached. Jakub Wartak and Robert Haas Backpatch to all supported versions Discussion: https://postgr

pgsql: Document limit on the number of out-of-line values per table

Document limit on the number of out-of-line values per table Document the hard limit stemming from the size of an OID, and also mention the perfomance impact that occurs before the hard limit is reached. Jakub Wartak and Robert Haas Backpatch to all supported versions Discussion: https://postgr

pgsql: Document limit on the number of out-of-line values per table

Document limit on the number of out-of-line values per table Document the hard limit stemming from the size of an OID, and also mention the perfomance impact that occurs before the hard limit is reached. Jakub Wartak and Robert Haas Backpatch to all supported versions Discussion: https://postgr

pgsql: Document limit on the number of out-of-line values per table

Document limit on the number of out-of-line values per table Document the hard limit stemming from the size of an OID, and also mention the perfomance impact that occurs before the hard limit is reached. Jakub Wartak and Robert Haas Backpatch to all supported versions Discussion: https://postgr

pgsql: Lower minimum maintenance_work_mem to 64kB

Lower minimum maintenance_work_mem to 64kB Since the introduction of TID store, vacuum uses far less memory in the common case than in versions 16 and earlier. Invoking multiple rounds of index vacuuming in turn requires a much larger table. It'd be a good idea anyway to cover this case in regress

pgsql: Lower minimum maintenance_work_mem to 64kB

Lower minimum maintenance_work_mem to 64kB Since the introduction of TID store, vacuum uses far less memory in the common case than in versions 16 and earlier. Invoking multiple rounds of index vacuuming in turn requires a much larger table. It'd be a good idea anyway to cover this case in regress

pgsql: Prevent access of uninitialized memory in radix tree nodes

Prevent access of uninitialized memory in radix tree nodes RT_NODE_16_SEARCH_EQ() performs comparisions using vector registers on x64-64 and aarch64. We apply a mask to the resulting bitfield to eliminate irrelevant bits that may be set. This ensures correct behavior, but Valgrind complains of the

pgsql: Small cosmetic fixes in radix tree template

Small cosmetic fixes in radix tree template - Bring memory context names in line with other naming - Fix typos, reported off-list by Alexander Lakhin - Remove copy-paste errors from comments - Remove duplicate #undef Branch -- master Details --- https://git.postgresql.org/pg/commitdiff/e

pgsql: Fix make headerscheck

Fix make headerscheck In the wake of commits dac048f71 and ecaf7c5df, `make headerscheck` no longer generated all headers that are included by other headers, causing headerscheck/cpluspluscheck to fail. To fix, backpatch enough makefile rules from 721856ff2 to generate all required headers. Repor

pgsql: Get rid of anonymous struct

Get rid of anonymous struct This is a C11 feature, and we require C99. While at it, go the further step and get rid of the surrounding union (with uintptr_t) entirely, as there is currently no use case for this file to access the header of BlocktableEntry as a uintptr_t, and there are no additiona

Re: pgsql: Teach radix tree to embed values at runtime

On Tue, Apr 9, 2024 at 12:27 AM Andres Freund wrote: > > This isn't quite C99 conformant, and thus breaks on the buildfarm animal > set up to test that: > https://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=mylodon&dt=2024-04-08%2012%3A07%3A01 I haven't forgotten about this and will fix withi

pgsql: Teach radix tree to embed values at runtime

Teach radix tree to embed values at runtime Previously, the decision to store values in leaves or within the child pointer was made at compile time, with variable length values using leaves by necessity. This commit allows introspecting the length of variable length values at runtime for that deci

pgsql: Teach TID store to skip bitmap for small numbers of offsets

Teach TID store to skip bitmap for small numbers of offsets The header portion of BlocktableEntry has enough padding space for an array of 3 offsets (1 on 32-bit platforms). Use this space instead of having a sparse bitmap array. This will take up a constant amount of space no matter what the offs

pgsql: Use bump context for TID bitmaps stored by vacuum

Use bump context for TID bitmaps stored by vacuum Vacuum does not pfree individual entries, and only frees the entire storage space when finished with it. This allows using a bump context, eliminating the chunk header in each leaf allocation. Most leaf allocations will be 16 to 32 bytes, so that's

pgsql: Fix alignment of stack variable

Fix alignment of stack variable Declare with union similar to PGAlignedBlock. Report and fix by Andres Freund Discussion: https://postgr.es/m/20240407190731.izm3mdazednrsiqk%40awork3.anarazel.de Branch -- master Details --- https://git.postgresql.org/pg/commitdiff/0ea51bac3802dca9dcf5

pgsql: Teach fasthash_accum to use platform endianness for bytewise loa

Teach fasthash_accum to use platform endianness for bytewise loads This function previously used a mix of word-wise loads and bytewise loads. The bytewise loads happened to be little-endian regardless of platform. This in itself is not a problem. However, a future commit will require the same resu

pgsql: Speed up tail processing when hashing aligned C strings, take tw

Speed up tail processing when hashing aligned C strings, take two After encountering the NUL terminator, the word-at-a-time loop exits and we must hash the remaining bytes. Previously we calculated the terminator's position and re-loaded the remaining bytes from the input string. This was slower t

pgsql: Add macro to disable address safety instrumentation

Add macro to disable address safety instrumentation fasthash_accum_cstring_aligned() uses a technique, found in various strlen() implementations, to detect a string's NUL terminator by reading a word at at time. That triggers failures when testing with "-fsanitize=address", at least with frontend

pgsql: Fix incorrect return type

Fix incorrect return type fasthash32() calculates a 32-bit hashcode, but the return type was uint64. Change to uint32. Noted by Jeff Davis Discussion: https://postgr.es/m/b16c93e6c736a422d4de668343515375664eb05d.camel%40j-davis.com Branch -- master Details --- https://git.postgresql.o

pgsql: Convert uses of hash_string_pointer to fasthash equivalent

Convert uses of hash_string_pointer to fasthash equivalent Remove duplicate hash_string_pointer() function definitions by creating a new inline function hash_string() for this purpose. This has the added advantage of avoiding strlen() calls when doing hash lookup. It's not clear how many of these

pgsql: Revert "Speed up tail processing when hashing aligned C strings"

Revert "Speed up tail processing when hashing aligned C strings" This reverts commit 07f0f6abfc7f6c55cede528d9689dedecefc734a. This has shown failures on both Valgrind and big-endian machines, per members skink and pike. Branch -- master Details --- https://git.postgresql.org/pg/commitd

Re: pgsql: Speed up tail processing when hashing aligned C strings

On Sun, Mar 31, 2024 at 12:32 PM John Naylor wrote: > > Speed up tail processing when hashing aligned C strings Skink reports valgrind error with Conditional jump or move depends on uninitialised value(s) I'll revert this soon to analyze, but first I'd like to see if any bi

pgsql: Speed up tail processing when hashing aligned C strings

shortening the dependency chain. Ants Aasma and John Naylor Discussion: https://postgr.es/m/CANwKhkP7pCiW_5fAswLhs71-JKGEz1c1%2BPC0a_w1fwY4iGMqUA%40mail.gmail.com Branch -- master Details --- https://git.postgresql.org/pg/commitdiff/07f0f6abfc7f6c55cede528d9689dedecefc734a

Re: pgsql: Add TIDStore, to store sets of TIDs (ItemPointerData) efficientl

On Tue, Mar 26, 2024 at 9:36 AM Masahiko Sawada wrote: > > On Tue, Mar 26, 2024 at 7:16 AM David Rowley wrote: > > > > Either "max_bytes" is a bad name for this variable or the * 1024L > > should be removed. > > > > Right. We discussed it on the original thread too[1]. Since we're > going to chan

Re: pgsql: Add template for adaptive radix tree

On Fri, Mar 8, 2024 at 10:43 AM David Rowley wrote: > > On Fri, 8 Mar 2024 at 16:37, John Naylor wrote: > > Thanks, I was getting close to committing a hackish workaround -- this > > seems better! > > ok cool. I also noticed a typo. Maybe worth fixing that at the same t

pgsql: Revert "Fix link error for test_radixtree module on Windows"

Revert "Fix link error for test_radixtree module on Windows" This reverts commit 9552e3ace317ac8bb0a80613c0e5cd6536c96dc8. I (john) forgot to revert this locally when a more principled fix was found, which has the same message title. Branch -- master Details --- https://git.postgresql.o

pgsql: Fix link error for test_radixtree module on Windows

Fix link error for test_radixtree module on Windows Add PGDLLIMPORT to pg_popcount32/64. In passing, fix a typo. Diagnosis by Masahiko Sawada, patch by David Rowley Per buildfarm members drongo and fairywren Discussion: https://postgr.es/m/CAD21AoAMm1mQd%3Dw4PrfrKK%3DOMP8j8%3D7ntJRPF8%2B%3D10i

pgsql: Fix link error for test_radixtree module on Windows

Fix link error for test_radixtree module on Windows Add back "link_with" directive, similar to the one removed by 1f1d73a8b, but only for Windows, but use the "_shlib" variation. Diagnosis by Masahiko Sawada, proposed fix adjusted and tested by me Per buildfarm members drongo and fairywren Disc

Re: pgsql: Add template for adaptive radix tree

On Fri, Mar 8, 2024 at 10:29 AM David Rowley wrote: > > On Fri, 8 Mar 2024 at 13:48, John Naylor wrote: > > Now, after I get some coffee I'll look into the Windows failures. > > I had a look at this and the attached fixes the broken build on MSVC for me. > > I

Re: pgsql: Add template for adaptive radix tree

On Thu, Mar 7, 2024 at 4:47 PM John Naylor wrote: > > On Thu, Mar 7, 2024 at 4:36 PM Alvaro Herrera wrote: > > > > Well, surely we can email them. Their profiles show they're still > > active. > > https://db.in.tum.de/people/sites/kemper/?lang=en > >

pgsql: Blind attempt to fix ODR violations

Blind attempt to fix ODR violations Remove apparently useless "link_with" directive. Even if this isn't the root cause, it makes the .build file more like the other test modules. Reviewed by Masahiko Sawada Follow-up to ee1b30f12, per buildfarm members olingo and grassquit. Discussion: https:/

Re: pgsql: Add template for adaptive radix tree

On Thu, Mar 7, 2024 at 4:36 PM Alvaro Herrera wrote: > > Well, surely we can email them. Their profiles show they're still > active. > https://db.in.tum.de/people/sites/kemper/?lang=en > https://db.in.tum.de/people/sites/neumann/?lang=en > https://db.in.tum.de/people/sites/leis/?lang=en I though

pgsql: Fix incorrect format specifier for int64

Fix incorrect format specifier for int64 Follow-up to ee1b30f12, per buildfarm member mamba. Discussion: https://postgr.es/m/CANWCAZYwyRMU%2BOTVOjK%3Dno1hm-W3ZQ5vrSFM1MFAaLtLydvwzA%40mail.gmail.com Branch -- master Details --- https://git.postgresql.org/pg/commitdiff/e444ebcb85c0b55b1c

pgsql: Fix redefinition of typedefs

Fix redefinition of typedefs Per buildfarm members sifaka and longfin, clang with -Wtypedef-redefinition warns of duplicate typedefs unless building with C11. Follow-up to ee1b30f12. Masahiko Sawada Discussion: https://postgr.es/m/CANWCAZauSg%3DLUbBbXhpeQtBuPifmzQNTYS6O8NsoAPz1zL-Txg%40mail.gma

Re: pgsql: Add template for adaptive radix tree

On Thu, Mar 7, 2024 at 1:32 PM Tom Lane wrote: > > John Naylor writes: > > On Thu, Mar 7, 2024 at 1:08 PM Tom Lane wrote: > >> Hm ... do we know that this is not patent-encumbered technology? > >> Commits citing such specific prior art make me nervous. >

Re: pgsql: Add template for adaptive radix tree

On Thu, Mar 7, 2024 at 1:08 PM Tom Lane wrote: > > John Naylor writes: > > This implements a radix tree data structure based on the design in > > "The Adaptive Radix Tree: ARTful Indexing for Main-Memory Databases" > > by Viktor Leis, Alfons Kemper, and ThomasNe

pgsql: Add template for adaptive radix tree

n in the same manner as simplehash.h and sort_template.h. Future commits will use this infrastructure for storing TIDs. Patch by Masahiko Sawada and John Naylor, but a substantial amount of credit is due to Andres Freund, whose proof-of-concept was a valuable source of coding idioms and awa

pgsql: Fix signedness error in 9f225e992 for gcc

Fix signedness error in 9f225e992 for gcc The first argument of vshrq_n_s8 needs to be a signed vector type, but it was passed unsigned. Clang is more lax with conversion, but gcc needs a cast. Fix by me, tested by Masahiko Sawada Per buildfarm members splitfin, batta, widowbird, snakefly, parul

pgsql: Introduce helper SIMD functions for small byte arrays

Introduce helper SIMD functions for small byte arrays vector8_min - helper for emulating ">=" semantics vector8_highbit_mask - used to turn the result of a vector comparison into a bitmask Masahiko Sawada Reviewed by Nathan Bossart, with additional adjustments by me Discussion: https://postgr.

pgsql: Move some bitmap logic out of bitmapset.c

Move some bitmap logic out of bitmapset.c Move the logic for selecting appropriate pg_bitutils.h functions based on word size to bitmapset.h for wider visibility. Reviewed (in a previous version) by Tom Lane Discussion: https://postgr.es/m/CAFBsxsFW2JjTo58jtDB%2B3sZhxMx3t-3evew8%3DAcr%2BGGhC%2Bk

pgsql: Fix warnings in cpluspluscheck

Fix warnings in cpluspluscheck Various int variables were compared to macros that are of type size_t, which caused -Wsign-compare warnings in cpluspluscheck. Change those to size_t, which also better describes their purpose. Per report from Peter Eisentraut Discussion: https://postgr.es/m/4868

pgsql: Further cosmetic review of hashfn_unstable.h

Further cosmetic review of hashfn_unstable.h In follow-up to e97b672c8, * Flesh out comments explaining the incremental interface * Clarify detection of zero bytes when hashing aligned C strings The latter was suggested and reviewed by Jeff Davis Discussion: https://postgr.es/m/48e8f8bbe0be9c78

pgsql: Simplify initialization of incremental hash state

Simplify initialization of incremental hash state The standalone functions fasthash{32,64} use length for two purposes: how many bytes to hash, and how to perturb the internal seed. Developers using the incremental interface may not know the length ahead of time (e.g. for C strings). In this case

pgsql: Fixed misspelled byteswap function for big endian machines

Fixed misspelled byteswap function for big endian machines Per members lora and mamba Branch -- master Details --- https://git.postgresql.org/pg/commitdiff/dd0a0cfc81fecacf2aed41b9eb138f850e43aab6 Modified Files -- src/include/common/hashfn_unstable.h | 2 +- 1 file changed,

pgsql: Add optimized C string hashing

ce that is written in assembly language. As demonstration, use this in the search path cache. This brings the general case performance closer to the special case optimization done in commit a86c61c9ee. There are other places that could benefit, but that is left for future work. Jeff Davis and J

pgsql: Add inline incremental hash functions for in-memory use

Add inline incremental hash functions for in-memory use It can be useful for a hash function to expose separate initialization, accumulation, and finalization steps. In particular, this is useful for building inline hash functions for simplehash. Instead of trying to whack around hash_bytes whil

pgsql: Update documentation of default fdw_tuple_cost

Update documentation of default fdw_tuple_cost Follow up to cac169d68 Umair Shahid Reviewed by Richard Guo and Chris Travers Discussion: https://postgr.es/m/CALVUYo9RECc5gwD%2B4SRM5Es%2Bbg9cpNfhd3_qUjf7kVTGyLpFJg%40mail.gmail.com Branch -- master Details --- https://git.postgresql.or

  1   2   3   >