From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Andres Freund <andres(at)anarazel(dot)de> |
Cc: | pgsql-hackers(at)lists(dot)postgresql(dot)org, Peter Eisentraut <peter(dot)eisentraut(at)enterprisedb(dot)com> |
Subject: | Re: Extending outfuncs support to utility statements |
Date: | 2022-07-10 23:12:52 |
Message-ID: | 816652.1657494772@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Andres Freund <andres(at)anarazel(dot)de> writes:
> On 2022-07-09 18:20:26 -0400, Tom Lane wrote:
>> For my taste, the circa 20K growth in outfuncs.o is an okay
>> price for being able to inspect utility statements more easily.
>> However, I'm less thrilled with the 30K growth in readfuncs.o,
>> because I can't see that we'd get any direct benefit from that.
>> So I think a realistic proposal is to enable outfuncs support
>> but keep readfuncs disabled.
> Another approach could be to mark those paths as "cold", so they are placed
> further away, reducing / removing potential overhead due to higher iTLB misses
> etc. 30K of disk space isn't worth worrying about.
They're not so much "cold" as "dead", so I don't see the point
of having them at all. If we ever start allowing utility commands
(besides NOTIFY) in stored rules, we'd need readfuncs support then
... but at least in the short run I don't see that happening.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Thomas Munro | 2022-07-10 23:19:18 | Re: AIX support - alignment issues |
Previous Message | Tom Lane | 2022-07-10 23:09:57 | Re: automatically generating node support functions |