| From: | Robert Haas <robertmhaas(at)gmail(dot)com> |
|---|---|
| To: | Heikki Linnakangas <hlinnaka(at)iki(dot)fi> |
| Cc: | Michael Paquier <michael(at)paquier(dot)xyz>, Alvaro Herrera <alvherre(at)alvh(dot)no-ip(dot)org>, "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-25 17:14:42 |
| Message-ID: | CA+TgmoZyi5VOh85fdNfadVfLckFy199x9_Q3Kg_eo7sTq2iwxw@mail.gmail.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On Thu, Jan 21, 2021 at 5:14 AM Heikki Linnakangas <hlinnaka(at)iki(dot)fi> wrote:
> Here you can see that as numsnaps increases, the test becomes slower,
> but then it becomes faster again at 64-66, when it switches to the hash
> table. So 64 seems too much. 32 seems to be the sweet spot here, that's
> where scanning the hash and scanning the array are about the same speed.
That sounds good. I mean, it could be that not all hardware behaves
the same here. But trying to get it into the right ballpark makes
sense.
I also like the fact that this now has some cases where it wins by a
significant margin. That's pretty cool; thanks for working on it!
--
Robert Haas
EDB: http://www.enterprisedb.com
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Jan Wieck | 2021-01-25 17:17:58 | Re: Extensibility of the PostgreSQL wire protocol |
| Previous Message | Robert Haas | 2021-01-25 17:05:24 | Re: Printing backtrace of postgres processes |