Re: CREATE INDEX and HOT (was Question: pg_classattributes and race conditions ?)
От | Russell Smith |
---|---|
Тема | Re: CREATE INDEX and HOT (was Question: pg_classattributes and race conditions ?) |
Дата | |
Msg-id | 4603356D.9090307@pws.com.au обсуждение исходный текст |
Ответ на | Re: CREATE INDEX and HOT (was Question: pg_classattributes and race conditions ?) ("Jim C. Nasby" <jim@nasby.net>) |
Список | pgsql-hackers |
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
В списке pgsql-hackers по дате отправления: