Re: Reducing relation locking overhead
От | Tom Lane |
---|---|
Тема | Re: Reducing relation locking overhead |
Дата | |
Msg-id | 8413.1133563510@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Re: Reducing relation locking overhead (Simon Riggs <simon@2ndquadrant.com>) |
Ответы |
Re: Reducing relation locking overhead
Re: Reducing relation locking overhead |
Список | pgsql-hackers |
Simon Riggs <simon@2ndquadrant.com> writes: > CREATE INDEX uses SnapshotAny, so the scan that feeds the build could > easily include rows added after the CREATE INDEX started. When the scan > was exhausted we could mark that last TID and return to it after the > sort/build. And do what? This has nothing to do with the fundamental problem of never being able to catch up unless you can upgrade your lock to exclude writes. What's worse, once you have excluded writes you have to rescan the entire table to be sure you haven't missed anything. So in the scenarios where this whole thing is actually interesting, ie enormous tables, you're still talking about a fairly long interval with writes locked out. Maybe not as long as a complete REINDEX, but long. regards, tom lane
В списке pgsql-hackers по дате отправления: