> On Mar 12, 2026, at 00:39, Greg Sabino Mullane <[email protected]> wrote:
>
> On Wed, Mar 11, 2026 at 3:05 AM Chao Li <[email protected]> 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 that would 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 to store the strings at all if you
> are tracking the action+rel. In such a case, the final strings can be created
> on the fly inside 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 rarely happen.
* If we take your approach, actually, we don’t have to store action+relation in
the list, only action is okay. But, if we defer 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 is to store the relation
name in a temp variable, which also introduces extra code. As a trade-off, I
think building the notice message in CollectPartitionNoRecurseNotice() is an
easy implementation.
Best regards,
--
Chao Li (Evan)
HighGo Software Co., Ltd.
https://www.highgo.com/
