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
