Re: Constraint Exclusion and Partition Locking
От | Hannu Krosing |
---|---|
Тема | Re: Constraint Exclusion and Partition Locking |
Дата | |
Msg-id | 1141500584.3772.15.camel@localhost.localdomain обсуждение исходный текст |
Ответ на | Constraint Exclusion and Partition Locking (Rod Taylor <pg@rbt.ca>) |
Список | pgsql-hackers |
Ühel kenal päeval, L, 2006-03-04 kell 13:16, kirjutas Rod Taylor: > Adding a new partition is fairly simple, particularly if you don't care > about writing RULEs to direct data into it and can rely on a bulk loader > to figure that part out. > > Removing a partition, on the other hand, is currently impossible to do > without blocking selects against the table as a whole. > > The reason for this is that when planning to see if a partition needs to > be read an AccessShareLock is taken and held for the entire transaction. > > If that lock was not there a partition (inherited table) could be > dropped without any interruptions to normal query processing. > > Is it possible to release the AccessShareLock lock on > "measurement_yy04mm03" after planning has determined that the structure > will not be used for this query in a "READ COMMITTED" transaction? > Serializable obviously would have problems with the partitions > constraint definition changing. Ar you sure ? I suspect that the change will not be visible to a serialisable trx. ------------- Hannu
В списке pgsql-hackers по дате отправления: