Re: Extending outfuncs support to utility statements

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

In response to

Responses

Browse pgsql-hackers by date

  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