Re: ALTER TABLE: warn when actions do not recurse to partitions
| От | Chao Li |
|---|---|
| Тема | Re: ALTER TABLE: warn when actions do not recurse to partitions |
| Дата | |
| Msg-id | A762E5CC-2BC3-4215-8A70-48281FEE2234@gmail.com обсуждение исходный текст |
| Ответ на | Re: ALTER TABLE: warn when actions do not recurse to partitions (Greg Sabino Mullane <htamfids@gmail.com>) |
| Ответы |
Re: ALTER TABLE: warn when actions do not recurse to partitions
|
| Список | pgsql-hackers |
> 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/
В списке pgsql-hackers по дате отправления: