simplehash: SH_OPTIMIZE_REPEAT for optimizing repeated lookups of the same key
Hackorum builds and tests every patch posted to the lists, not only commitfest submissions. This is Hackorum's own CI rather than the PostgreSQL project's, and it is still under testing - please report anything that looks wrong.
You can run a PostgreSQL built from this patch straight from Docker, with no checkout and no build:
docker run --rm -p 5432:5432 ghcr.io/hackorum-dev/postgres-patch:t48763psql -h localhost -U postgresBuilt from patchset v1 (message #1), September 20, 2026 at 04:58 AM.
Every patchset is also pushed to a branch of our PostgreSQL fork, so you can check out the same tree CI built. Without a PostgreSQL checkout:
git clone --branch t48763_1 https://github.com/hackorum-dev/postgres.gitIn a checkout you already have, add the fork once:
git remote add hackorum https://github.com/hackorum-dev/postgres.gitthen, for this patchset and every later one:
git fetch hackorum t48763_1 && git checkout t48763_1Patchset v1 (message #1) is on t48763_1
Patch attached.
The caller could do something similar, so this option is not necessary,
but it seems like it could be generally useful. It speeds things up for
the search_path cache (and is an alternative to another patch I have
that implements the same thing in the caller).
Thoughts?
Regards,
Jeff Davis
On Mon, Nov 20, 2023 at 06:12:47PM -0800, Jeff Davis wrote:
The caller could do something similar, so this option is not necessary,
but it seems like it could be generally useful. It speeds things up for
the search_path cache (and is an alternative to another patch I have
that implements the same thing in the caller).
I'm mostly thinking out loud here, but could we just always do this? I
guess you might want to avoid it if your SH_EQUAL is particularly expensive
and you know repeated lookups are rare, but maybe that's uncommon enough
that we don't really care.
--
Nathan Bossart
Amazon Web Services: https://aws.amazon.com
On Mon, 2023-11-20 at 22:50 -0600, Nathan Bossart wrote:
I'm mostly thinking out loud here, but could we just always do this?
I
guess you might want to avoid it if your SH_EQUAL is particularly
expensive
and you know repeated lookups are rare, but maybe that's uncommon
enough
that we don't really care.
I like that simplehash is simple, so I'm not inclined to introduce an
always-on feature.
It would be interesting to know how often it's a good idea to turn it
on, though. I could try turning it on for various other uses of
simplehash, and see where it tends to win.
The caller can also save the hash and pass it down, but that's not
always convenient to do.
Regards,
Jeff Davis
On Mon, Nov 20, 2023 at 10:37:47PM -0800, Jeff Davis wrote:
It would be interesting to know how often it's a good idea to turn it
on, though. I could try turning it on for various other uses of
simplehash, and see where it tends to win.
That seems worthwhile to me.
--
Nathan Bossart
Amazon Web Services: https://aws.amazon.com
Hi,
On 2023-11-20 22:37:47 -0800, Jeff Davis wrote:
On Mon, 2023-11-20 at 22:50 -0600, Nathan Bossart wrote:
I'm mostly thinking out loud here, but could we just always do this?�
I
guess you might want to avoid it if your SH_EQUAL is particularly
expensive
and you know repeated lookups are rare, but maybe that's uncommon
enough
that we don't really care.I like that simplehash is simple, so I'm not inclined to introduce an
always-on feature.
I think it'd be a bad idea to make it always on - there's plenty cases where
it just would make things slower because the hit rate is low. A equal
comparison is far from free.
I am not quite sure this kind of cache best lives in simplehash - ISTM that
quite often it'd be more beneficial to have a cache that you can test more
cheaply higher up.
Greetings,
Andres Freund
On Tue, 2023-11-21 at 08:51 -0800, Andres Freund wrote:
I am not quite sure this kind of cache best lives in simplehash -
ISTM that
quite often it'd be more beneficial to have a cache that you can test
more
cheaply higher up.
Yeah. I suppose when a few more callers are likely to benefit we can
reconsider.
Though it makes it easy to test a few other callers, just to see what
numbers appear.
Regards,
Jeff Davis