Jim C. Nasby wrote:
> 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 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.
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?
Regards
Russell Smith
