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
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 repeat
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
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
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 th
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,
