| From: | Heikki Linnakangas <hlinnaka(at)iki(dot)fi> |
|---|---|
| To: | Alvaro Herrera <alvherre(at)alvh(dot)no-ip(dot)org> |
| Cc: | "kuroda(dot)hayato(at)fujitsu(dot)com" <kuroda(dot)hayato(at)fujitsu(dot)com>, "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org> |
| Subject: | Re: ResourceOwner refactoring |
| Date: | 2021-01-18 15:19:04 |
| Message-ID: | 113f69b8-04f4-93be-1bae-0c2dfa40426d@iki.fi |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
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.
- Heikki
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Drouvot, Bertrand | 2021-01-18 15:19:31 | Standby recovery conflicts: add information when the cancellation occurs |
| Previous Message | Zhihong Yu | 2021-01-18 15:04:20 | Re: New IndexAM API controlling index vacuum strategies |