> On Mar 12, 2026, at 00:39, Greg Sabino Mullane <htamfids@gmail.com> wrote:
>
> On Wed, Mar 11, 2026 at 3:05 AM Chao Li <li.evan.chao@gmail.com> wrote:
> Are you concerning that rendering the full message text is the extra work? This is not a hot path, so I don’t think
thatwould be a big deal. Actually, adding two more fields sounds more expensive
>
> Well, the recurring creation and freeing of the strings is the part that seems inefficient. But you don't even need
tostore the strings at all if you are tracking the action+rel. In such a case, the final strings can be created on the
flyinside of EmitPartitionNoRecurseNotice, right? Then you just need a list to store the combos of action+relation.
>
Fully understood your point. My considerations are:
* This is not on a hot path, and that’s a very trivial performance impact.
* I would believe in most of use cases, ALTER TABLE won’t take duplicate sub-commands, thus duplicated messages should
rarelyhappen.
* If we take your approach, actually, we don’t have to store action+relation in the list, only action is okay. But, if
wedefer building the notice message to EmitPartitionNoRecurseNotice, then we have to leave relation open till
EmitPartitionNoRecurseNotice,which feels a worse burden. Looking at ATController(), rel is closed early. An alternative
isto store the relation name in a temp variable, which also introduces extra code. As a trade-off, I think building the
noticemessage in CollectPartitionNoRecurseNotice() is an easy implementation.
Best regards,
--
Chao Li (Evan)
HighGo Software Co., Ltd.
https://www.highgo.com/