public inbox for [email protected]
help / color / mirror / Atom feed[PATCH v6 3/3] Optimize hash function
2+ messages / 2 participants
[nested] [flat]
* [PATCH v6 3/3] Optimize hash function
@ 2021-01-20 22:06 Heikki Linnakangas <[email protected]>
0 siblings, 0 replies; 2+ messages in thread
From: Heikki Linnakangas @ 2021-01-20 22:06 UTC (permalink / raw)
---
src/backend/utils/resowner/resowner.c | 24 ++++++++++++++++++------
src/include/common/hashfn.h | 15 +++++++++++++++
2 files changed, 33 insertions(+), 6 deletions(-)
diff --git a/src/backend/utils/resowner/resowner.c b/src/backend/utils/resowner/resowner.c
index 1db1e7cf14b..72e4d8a784c 100644
--- a/src/backend/utils/resowner/resowner.c
+++ b/src/backend/utils/resowner/resowner.c
@@ -163,15 +163,27 @@ static void ReleaseAuxProcessResourcesCallback(int code, Datum arg);
* INTERNAL ROUTINES *
*****************************************************************************/
+/*
+ * Hash function for value+kind combination.
+ */
static inline uint32
hash_resource_elem(Datum value, ResourceOwnerFuncs *kind)
{
- Datum data[2];
-
- data[0] = value;
- data[1] = PointerGetDatum(kind);
-
- return hash_bytes((unsigned char *) &data, 2 * SIZEOF_DATUM);
+ /*
+ * Most resources types store a pointer in 'value', and pointers are
+ * unique all on their own. But some resources store plain integers (Files
+ * and Buffers as of this writing), so we want to incorporate the 'kind'
+ * in the hash too, otherwise those resources will collide a lot. But
+ * because there are only a few resource kinds like that - and only a few
+ * resource kinds to begin with - we don't need to work too hard to mix
+ * 'kind' into the hash. Just add it with hash_combine(), it perturbs the
+ * result enough for our purposes.
+ */
+#if SIZEOF_DATUM == 8
+ return hash_combine64(murmurhash64((uint64) value), (uint64) kind);
+#else
+ return hash_combine(murmurhash32((uint32) value), (uint32) kind);
+#endif
}
static void
diff --git a/src/include/common/hashfn.h b/src/include/common/hashfn.h
index c634cc067a1..009ffbbdd38 100644
--- a/src/include/common/hashfn.h
+++ b/src/include/common/hashfn.h
@@ -101,4 +101,19 @@ murmurhash32(uint32 data)
return h;
}
+/* 64-bit variant */
+static inline uint64
+murmurhash64(uint64 data)
+{
+ uint64 h = data;
+
+ h ^= h >> 33;
+ h *= 0xff51afd7ed558ccd;
+ h ^= h >> 33;
+ h *= 0xc4ceb9fe1a85ec53;
+ h ^= h >> 33;
+
+ return h;
+}
+
#endif /* HASHFN_H */
--
2.29.2
--------------F30A5443A5D524A5CBC51AE7
Content-Type: text/x-patch; charset=UTF-8;
name="v2-0001-resownerbench.patch"
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment;
filename="v2-0001-resownerbench.patch"
^ permalink raw reply [nested|flat] 2+ messages in thread
* IPC::Run accepts bug reports
@ 2024-06-15 23:48 Noah Misch <[email protected]>
0 siblings, 0 replies; 2+ messages in thread
From: Noah Misch @ 2024-06-15 23:48 UTC (permalink / raw)
To: Robert Haas <[email protected]>; +Cc: pgsql-hackers
Separating this from the pytest thread:
On Sat, Jun 15, 2024 at 01:26:57PM -0400, Robert Haas wrote:
> The one
> thing I know about that *I* think is a pretty big problem about Perl
> is that IPC::Run is not really maintained.
I don't see in https://github.com/cpan-authors/IPC-Run/issues anything
affecting PostgreSQL. If you know of IPC::Run defects, please report them.
If I knew of an IPC::Run defect affecting PostgreSQL, I likely would work on
it before absurdity like https://github.com/cpan-authors/IPC-Run/issues/175
NetBSD-10-specific behavior coping.
^ permalink raw reply [nested|flat] 2+ messages in thread
end of thread, other threads:[~2024-06-15 23:48 UTC | newest]
Thread overview: 2+ messages (download: mbox mbox.gz follow: Atom feed)
-- links below jump to the message on this page --
2021-01-20 22:06 [PATCH v6 3/3] Optimize hash function Heikki Linnakangas <[email protected]>
2024-06-15 23:48 IPC::Run accepts bug reports Noah Misch <[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