Re: BUG #16818: progress reporting ALTER TABLE ADD UNIQUE
От | Tom Lane |
---|---|
Тема | Re: BUG #16818: progress reporting ALTER TABLE ADD UNIQUE |
Дата | |
Msg-id | 1038256.1610403147@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Re: BUG #16818: progress reporting ALTER TABLE ADD UNIQUE (Alvaro Herrera <alvherre@alvh.no-ip.org>) |
Список | pgsql-bugs |
Alvaro Herrera <alvherre@alvh.no-ip.org> writes: > On 2021-Jan-11, PG Bug reporting form wrote: >> The progress reprorting for `ALTER TABLE test ADD UNIQUE (col)` is in >> `pg_stat_progress_create_index`. As it indeed creates an index, that is not >> too unexpected, but the `command` column of that view reports `CREATE >> INDEX`, and _that_ is somewhat unexpected. A reasonable expectation would be >> `ALTER TABLE ADD CONSTRAINT` or comparable. > Hmm, seems a reasonable complaint. Are there other command wordings > that would need to be handled? I can't think of any (but I already > overlooked this one, evidently ...) TBH, I think that reporting it as "CREATE INDEX" is good, and what the OP is asking for is less good. Creating an index is what is actually the time-consuming step here --- making the catalog entries for the constraint is negligible. Also, just how picky would we be about replicating the command spelling -- e.g., consider "ALTER TABLE t ADD PRIMARY KEY(p)" vs "ALTER TABLE t ADD CONSTRAINT c PRIMARY KEY(p)" vs "ALTER TABLE t ADD COLUMN c int PRIMARY KEY" vs all the same options for UNIQUE vs all the same options for EXCLUSION vs yadda yadda. That is not going to be helpful to anybody, IMO, especially not automated tools that might be watching the progress view. It's reasonable for the view to distinguish REINDEX and CONCURRENTLY options, as those are relevant to performance, but I don't think we should add purely-cosmetic variations. regards, tom lane
В списке pgsql-bugs по дате отправления: