Re: CREATE INDEX and HOT (was Question:pg_classattributes and race conditions ?)
От | Simon Riggs |
---|---|
Тема | Re: CREATE INDEX and HOT (was Question:pg_classattributes and race conditions ?) |
Дата | |
Msg-id | 1174320505.4160.818.camel@silverbirch.site обсуждение исходный текст |
Ответ на | Re: CREATE INDEX and HOT (was Question: pg_classattributes and race conditions ?) ("Merlin Moncure" <mmoncure@gmail.com>) |
Список | pgsql-hackers |
On Mon, 2007-03-19 at 10:29 -0500, Merlin Moncure wrote: > On 3/17/07, Simon Riggs <simon@2ndquadrant.com> wrote: > > I'm very comfortable with the idea that HOT can be turned on/off for a > > table. That gives us a workaround to bugs. Previously, changing things > > like WITHOUT OIDS was done over two releases, so I'd suggest the same > > thing here. Add the option now, disabled, then look to make it the > > default option in the next release. We can override that with the > > default_use_hot parameter for those that feel bold, at least initially. > > I know Bruce has been long opposed to the idea of a table-level switch, > > which is why we've been trying so hard to avoid it. So we should add his > > -1 to this idea from the start. > > Is fear of bugs a justification of guc setting? Probably not on its own, but the inspiration was that we currently have user-visible behaviour in the recent proposals, hence the GUC. > Or is there a trade-off involved with HOT? At the moment, there is no downside to HOT in normal operation that I'm aware of, but its a great question. The problem we have is with normal CREATE INDEX because there are two sources of race conditions that complicate this: concurrent index scans and crash safety. Currently there are no perfect solutions to this. We have two main options: 1. additional locking, either within CIDX or as a separate DDL 2. additional complexity and possible limitation in the number of indexes to just 3 before we stop doing HOT updates. -- Simon Riggs EnterpriseDB http://www.enterprisedb.com
В списке pgsql-hackers по дате отправления: