On Mon, 2007-03-19 at 10:29 -0500, Merlin Moncure wrote: > On 3/17/07, Simon Riggs <[EMAIL PROTECTED]> 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 ---------------------------(end of broadcast)--------------------------- TIP 9: In versions below 8.0, the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
