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: | Raw Message | Whole Thread | 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 |