Re: [DOC] Document concurrent index builds waiting on each other
От | James Coleman |
---|---|
Тема | Re: [DOC] Document concurrent index builds waiting on each other |
Дата | |
Msg-id | CAAaqYe9Qzx5wcL1qPVPe5wOPxnyFgsXv4dSyrpPY-PUpWmiM_w@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: [DOC] Document concurrent index builds waiting on each other (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: [DOC] Document concurrent index builds waiting on each other
|
Список | pgsql-hackers |
On Wed, Jan 13, 2021 at 5:00 PM Tom Lane <tgl@sss.pgh.pa.us> wrote: > > James Coleman <jtc331@gmail.com> writes: > > On Wed, Jan 13, 2021 at 4:29 PM Tom Lane <tgl@sss.pgh.pa.us> wrote: > >> but the antecedent of "a table" is a bit unclear; people might > >> wonder if it means the table being reindexed. > > > It does mean the table being reindexed; the last phrase says "any > > table" meaning "any other table". > > [ raised eyebrow ] Surely REINDEX and VACUUM can't run on the same > table at the same time. + Like any long-running transaction, <command>CREATE INDEX</command> on a + table can affect which tuples can be removed by concurrent + <command>VACUUM</command> on any other table. The "on a table" is the table on which the REINDEX/CREATE INDEX is occurring. The "any other table" is where VACUUM might run. James
В списке pgsql-hackers по дате отправления: