From: | Jeff Davis <pgsql(at)j-davis(dot)com> |
---|---|
To: | Nathan Bossart <nathandbossart(at)gmail(dot)com> |
Cc: | Isaac Morland <isaac(dot)morland(at)gmail(dot)com>, pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: Faster "SET search_path" |
Date: | 2023-11-21 01:13:33 |
Message-ID: | 32c6972c9434fa6d7128311add5887079c58f7a4.camel@j-davis.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Thu, 2023-11-16 at 16:46 -0800, Jeff Davis wrote:
> While I considered OOM during hash key initialization, I missed some
> other potential out-of-memory hazards. Attached a fixup patch 0003,
> which re-introduces one list copy but it simplifies things
> substantially in addition to being safer around OOM conditions.
Committed 0003 fixup.
> > > 0004: Use the same cache to optimize check_search_path().
Committed 0004.
> > > 0005: Optimize cache for repeated lookups of the same value.
Will commit 0005 soon.
I also attached a trivial 0006 patch that uses SH_STORE_HASH. I wasn't
able to show much benefit, though, even when there's a bucket
collision. Perhaps there just aren't enough elements to matter -- I
suppose there would be a benefit if there are lots of unique
search_path strings, but that doesn't seem very plausible to me. If
someone thinks it's worth committing, then I will, but I don't see any
real upside or downside.
Regards,
Jeff Davis
Attachment | Content-Type | Size |
---|---|---|
v10-0002-Use-SH_STORE_HASH-for-search_path-cache.patch | text/x-patch | 1.6 KB |
v10-0001-Optimize-SearchPathCache-by-saving-the-last-entr.patch | text/x-patch | 4.4 KB |
From | Date | Subject | |
---|---|---|---|
Next Message | Michael Paquier | 2023-11-21 01:25:48 | Re: Adding facility for injection points (or probe points?) for more advanced tests |
Previous Message | Alena Rybakina | 2023-11-21 00:50:15 | Re: POC, WIP: OR-clause support for indexes |