Re: Faster "SET search_path"

Поиск
Список
Период
Сортировка
От Jeff Davis
Тема Re: Faster "SET search_path"
Дата
Msg-id 7e8d116e4ea8c0ba059876267c9b6bbb7fec8a0d.camel@j-davis.com
обсуждение исходный текст
Ответ на Re: Faster "SET search_path"  (Nathan Bossart <nathandbossart@gmail.com>)
Список pgsql-hackers
On Tue, 2023-08-01 at 21:52 -0700, Nathan Bossart wrote:
> I
> typically see this done with two ѕeparate lists and forboth().

Agreed, done.

>
> Any reason not to use hash_combine() here?

Thank you, fixed.

> > I changed it to move the hook so that it's called after retrieving
> > from
> > the cache.
...
> I think you are right.  This adds some complexity, but I don't have
> anything else to propose at the moment.

I reworked it a bit to avoid allocations in most cases, and it only
reprocesses the oidlist and runs the hooks when necessary (and even
then, still benefits from the cached OIDs that have already passed the
ACL checks).

Now I'm seeing timings around 7.1s, which is starting to look really
nice.

>
> I'm not following why this logic was moved.

There was previously a comment:

    "We want to detect the case where the effective value of the base
search path variables didn't change.  As long as we're doing so, we can
avoid copying the OID list unnecessarily."

But with v2 the copy had already happened by that point. In v3, there
is no copy at all.
>

Regards,
    Jeff Davis



Вложения

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

Предыдущее
От: Andy Fan
Дата:
Сообщение: Re: Fix incorrect start up costs for WindowAgg paths (bug #17862)
Следующее
От: tender wang
Дата:
Сообщение: Re: [BUG] Fix DETACH with FK pointing to a partitioned table fails