Jim C. Nasby wrote:
I thought about making it even simpler. Only allow CREATE INDEX builds
on non HOT tables. However as I mentioned in another thread, this idea
dies if you expect to be able to have HOT enabled by default in any
future release. Chilling needs to be able to be done with a regular
Vacuum style lock for chilling to be a usable reality.
On Mon, Mar 19, 2007 at 12:05:19PM +0000, Simon Riggs wrote:
I was unwilling to compromise to have HOT if only one index existed, but
IMHO allowing HOT with <= 3 indexes is an acceptable compromise for this
release. (We can always use vertical partitioning techniques to allow
additional access paths to be added to the same table - I'd be very
happy to document that with worked examples, if requried).
I'm not sure where we're sitting with this, but I've got another idea I
haven't seen (one that I think is better than an arbitrary limit on the
number of indexes)... what if we just disallow non-concurrent index
builds on hot tables? It sounds like the additional pain involved in
chilling an entire table and keeping it chilled for the index build is
even more overhead than just doing a concurrent index build.
I'm sure there are use cases or this, but it seems unlikely that a high
update table is going to have an index added to it. Am I a long way
from reality when saying that?
---------------------------(end of broadcast)---------------------------
TIP 1: if posting/reading through Usenet, please send an appropriate
subscribe-nomail command to [EMAIL PROTECTED] so that your
message can get through to the mailing list cleanly