Horton

Re: Faster "SET search_path"

Jeff Davis <pgsql@j-davis.com>

View thread View on postgr.es
From: Jeff Davis <pgsql@j-davis.com>
To: Nathan Bossart <nathandbossart@gmail.com>
Cc: Isaac Morland <isaac.morland@gmail.com>, pgsql-hackers@postgresql.org
Date: 2023-12-05T23:55:11Z
Lists: pgsql-hackers 
On Mon, 2023-11-20 at 17:13 -0800, Jeff Davis wrote:
> Will commit 0005 soon.

Committed.

> 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.

I tried again by forcing a hash table with ~25 entries and 13
collisions, and even then, SH_STORE_HASH didn't make a difference in my
test. Maybe a microbenchmark would show a difference, but I didn't see
much reason to commit 0006. (There's also no downside, so I was tempted
to commit it just so I wouldn't have to put more thought into whether
it's a problem or not.)

Regards,
	Jeff Davis

Commits

  1. Fix missing invalidations for search_path cache.

  2. Optimize SearchPathCache by saving the last entry.

  3. Optimize check_search_path() by using SearchPathCache.

  4. Be more paranoid about OOM in search_path cache.

  5. Add cache for recomputeNamespacePath().

  6. Transform proconfig for faster execution.