database/postgres
1
0
Fork 0
mirror of https://github.com/postgres/postgres.git synced 2025-11-19 13:42:17 +03:00
Code Activity

Grab the low-hanging fruit from forcing sizeof(Datum) to 8.

Browse Source 
Remove conditionally-compiled code for smaller Datum widths,
and simplify comments that describe cases no longer of interest.

I also fixed up a few more places that were not using
DatumGetIntXX where they should, and made some cosmetic
adjustments such as using sizeof(int64) not sizeof(Datum)
in places where that fit better with the surrounding code.

One thing I remembered while preparing this part is that SP-GiST
stores pass-by-value prefix keys as Datums, so that the on-disk
representation depends on sizeof(Datum).  That's even more
unfortunate than the existing commentary makes it out to be,
because now there is a hazard that the change of sizeof(Datum)
will break SP-GiST indexes on 32-bit machines.  It appears that
there are no existing SP-GiST opclasses that are actually
affected; and if there are some that I didn't find, the number
of installations that are using them on 32-bit machines is
doubtless tiny.  So I'm proceeding on the assumption that we
can get away with this, but it's something to worry about.

(gininsert.c looks like it has a similar problem, but it's okay
because the "tuples" it's constructing are just transient data
within the tuplesort step.  That's pretty poorly documented
though, so I added some comments.)

Author: Tom Lane <tgl@sss.pgh.pa.us>
Reviewed-by: Peter Eisentraut <peter@eisentraut.org>
Discussion: https://postgr.es/m/1749799.1752797397@sss.pgh.pa.us
This commit is contained in:
Tom Lane
2025-08-13 17:11:54 -04:00
parent 2a600a93c7
commit 6aebedc384
17 changed files with 72 additions and 284 deletions
Download Patch File Download Diff File Expand all files Collapse all files

27
src/backend/utils/adt/varlena.c
View File

@@ -1671,14 +1671,13 @@ varstr_sortsupport(SortSupport ssup, Oid typid, Oid collid)
*
* Even apart from the risk of broken locales, it's possible that
* there are platforms where the use of abbreviated keys should be
* disabled at compile time. Having only 4 byte datums could make
* worst-case performance drastically more likely, for example.
* Moreover, macOS's strxfrm() implementation is known to not
* effectively concentrate a significant amount of entropy from the
* original string in earlier transformed blobs. It's possible that
* other supported platforms are similarly encumbered. So, if we ever
* get past disabling this categorically, we may still want or need to
* disable it for particular platforms.
* disabled at compile time. For example, macOS's strxfrm()
* implementation is known to not effectively concentrate a
* significant amount of entropy from the original string in earlier
* transformed blobs. It's possible that other supported platforms
* are similarly encumbered. So, if we ever get past disabling this
* categorically, we may still want or need to disable it for
* particular platforms.
*/
if (!pg_strxfrm_enabled(locale))
abbreviate = false;
@@ -2132,18 +2131,12 @@ varstr_abbrev_convert(Datum original, SortSupport ssup)
addHyperLogLog(&sss->full_card, hash);
/* Hash abbreviated key */
#if SIZEOF_DATUM == 8
{
uint32 lohalf,
hihalf;
uint32 tmp;
lohalf = (uint32) res;
hihalf = (uint32) (res >> 32);
hash = DatumGetUInt32(hash_uint32(lohalf ^ hihalf));
tmp = DatumGetUInt32(res) ^ (uint32) (DatumGetUInt64(res) >> 32);
hash = DatumGetUInt32(hash_uint32(tmp));
}
#else /* SIZEOF_DATUM != 8 */
hash = DatumGetUInt32(hash_uint32((uint32) res));
#endif
addHyperLogLog(&sss->abbr_card, hash);