Re: ResourceOwner refactoring

Поиск
Список
Период
Сортировка
От Heikki Linnakangas
Тема Re: ResourceOwner refactoring
Дата
Msg-id 76a0b012-14ed-bcfd-cf40-af084dba8a11@iki.fi
обсуждение исходный текст
Ответ на Re: ResourceOwner refactoring  (Robert Haas <robertmhaas@gmail.com>)
Ответы Re: ResourceOwner refactoring  (Heikki Linnakangas <hlinnaka@iki.fi>)
Список pgsql-hackers
On 18/01/2021 18:11, Robert Haas wrote:
> On Mon, Jan 18, 2021 at 11:11 AM Robert Haas <robertmhaas@gmail.com> wrote:
>> On Mon, Jan 18, 2021 at 10:19 AM Heikki Linnakangas <hlinnaka@iki.fi> wrote:
>>> On 18/01/2021 16:34, Alvaro Herrera wrote:
>>>> So according to your performance benchmark, we're willing to accept a
>>>> 30% performance loss on an allegedly common operation -- numkeep=0
>>>> numsnaps=10 becomes 49.8ns from 37.6ns.  That seems a bit shocking.
>>>> Maybe you can claim that these operations aren't exactly hot spots, and
>>>> so the fact that we remain in the same power-of-ten is sufficient.  Is
>>>> that the argument?
>>>
>>> That's right. The fast path is fast, and that's important. The slow path
>>> becomes 30% slower, but that's acceptable.
> 
> I don't know whether a 30% slowdown will hurt anybody, but it seems
> like kind of a lot, and I'm not sure I understand what corresponding
> benefit we're getting.

The benefit is to make it easy for extensions to use resource owners to 
track whatever resources they need to track. And arguably, the new 
mechanism is nicer for built-in code, too.

I'll see if I can optimize the slow paths, to make it more palatable.

- Heikki



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

Предыдущее
От: Peter Smith
Дата:
Сообщение: Re: Single transaction in the tablesync worker?
Следующее
От: Noah Misch
Дата:
Сообщение: Re: Wrong usage of RelationNeedsWAL