Re: Slow GRANT ROLE on PostgreSQL 16 with thousands of ROLEs

Поиск
Список
Период
Сортировка
От Nathan Bossart
Тема Re: Slow GRANT ROLE on PostgreSQL 16 with thousands of ROLEs
Дата
Msg-id 20240326165918.GA3350222@nathanxps13
обсуждение исходный текст
Ответ на Re: Slow GRANT ROLE on PostgreSQL 16 with thousands of ROLEs  (Nathan Bossart <nathandbossart@gmail.com>)
Ответы Re: Slow GRANT ROLE on PostgreSQL 16 with thousands of ROLEs  (Tom Lane <tgl@sss.pgh.pa.us>)
Список pgsql-hackers
Here is a new version of the patch that I feel is in decent shape.

On Mon, Mar 25, 2024 at 10:16:47AM -0500, Nathan Bossart wrote:
> On Mon, Mar 25, 2024 at 11:08:39AM -0400, Tom Lane wrote:
>> * The magic constants (crossover list length and bloom filter size)
>> need some testing to see if there are better values.  They should
>> probably be made into named #defines, too.  I suspect, with little
>> proof, that the bloom filter size isn't particularly critical --- but
>> I know we pulled the crossover of 1000 out of thin air, and I have
>> no certainty that it's even within an order of magnitude of being a
>> good choice.
> 
> I'll try to construct a couple of tests to see if we can determine a proper
> order of magnitude.

I spent some time trying to get some ballpark figures but have thus far
been unsuccessful.  Even if I was able to get good numbers, I'm not sure
how much they'd help us, as we'll still need to decide how much overhead we
are willing to take in comparison to the linear search.  I don't think
~1000 is an unreasonable starting point, as it seems generally more likely
that you will have many more roles to process at that point than if the
threshold was, say, 100.  And if the threshold is too high (e.g., 10,000),
this optimization will only kick in for the most extreme cases, so we'd
likely be leaving a lot on the table.  But, I will be the first to admit
that my reasoning here is pretty unscientific, and I'm open to suggestions
for how to make it less so.

-- 
Nathan Bossart
Amazon Web Services: https://aws.amazon.com

Вложения

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

Предыдущее
От: Bertrand Drouvot
Дата:
Сообщение: Re: pgsql: Track last_inactive_time in pg_replication_slots.
Следующее
От: Alexander Lakhin
Дата:
Сообщение: Re: Properly pathify the union planner