Re: Faster "SET search_path"

Поиск
Список
Период
Сортировка
От Jeff Davis
Тема Re: Faster "SET search_path"
Дата
Msg-id 32c6972c9434fa6d7128311add5887079c58f7a4.camel@j-davis.com
обсуждение исходный текст
Ответ на Re: Faster "SET search_path"  (Jeff Davis <pgsql@j-davis.com>)
Ответы Re: Faster "SET search_path"
Список 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


Вложения

В списке pgsql-hackers по дате отправления:

Предыдущее
От: Alena Rybakina
Дата:
Сообщение: Re: POC, WIP: OR-clause support for indexes
Следующее
От: Michael Paquier
Дата:
Сообщение: Re: Adding facility for injection points (or probe points?) for more advanced tests