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

Reply via email to