| From: | John Naylor <john(dot)naylor(at)2ndquadrant(dot)com> |
|---|---|
| To: | Heikki Linnakangas <hlinnaka(at)iki(dot)fi> |
| Cc: | PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org> |
| Subject: | Re: reduce size of fmgr_builtins array |
| Date: | 2020-01-18 04:52:26 |
| Message-ID: | CACPNZCt72iZ-z9oHsTwT30FMxjvxQfMOPjuZ2O5N0Vnd_aL99Q@mail.gmail.com |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On Tue, Jan 7, 2020 at 9:08 PM Heikki Linnakangas <hlinnaka(at)iki(dot)fi> wrote:
> Yeah. Nevertheless, it would be nice to be able to demonstrate the
> benefit in some test, at least. It feels hard to justify committing a
> performance patch if we can't show the benefit. Otherwise, we should
> just try to keep it as simple as possible, to optimize for readability.
>
> A similar approach was actually discussed a couple of years back:
> https://www.postgresql.org/message-id/bd13812c-c4ae-3788-5b28-5633beed2929%40iki.fi.
> The conclusion then was that it's not worth the trouble or the code
> complication. So I think this patch is Rejected, unless you can come up
> with a test case that concretely shows the benefit.
Thanks for reviewing! As expected, a microbenchmark didn't show a
difference. I could try profiling in some workload, but I don't think
the benefit would be worth the effort involved. I've marked it
rejected.
--
John Naylor https://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Amit Kapila | 2020-01-18 05:29:49 | Re: Reorderbuffer crash during recovery |
| Previous Message | Michael Paquier | 2020-01-18 03:48:05 | Re: PATCH: standby crashed when replay block which truncated in standby but failed to truncate in master node |