Re: ResourceOwner refactoring
От | Robert Haas |
---|---|
Тема | Re: ResourceOwner refactoring |
Дата | |
Msg-id | CA+TgmoZNk2cn_vkYzw7dxCf=ECDZFW15VB_5MFfK5e_8-a57+w@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: ResourceOwner refactoring (Robert Haas <robertmhaas@gmail.com>) |
Ответы |
Re: ResourceOwner refactoring
|
Список | pgsql-hackers |
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. Sorry for the empty message. 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. -- Robert Haas EDB: http://www.enterprisedb.com
В списке pgsql-hackers по дате отправления: