Re: ALTER TABLE SET STATISTICS requires AccessExclusiveLock
От | Simon Riggs |
---|---|
Тема | Re: ALTER TABLE SET STATISTICS requires AccessExclusiveLock |
Дата | |
Msg-id | 1279307553.1735.40190.camel@ebony обсуждение исходный текст |
Ответ на | Re: ALTER TABLE SET STATISTICS requires AccessExclusiveLock (Andres Freund <andres@anarazel.de>) |
Ответы |
Re: ALTER TABLE SET STATISTICS requires AccessExclusiveLock
|
Список | pgsql-hackers |
On Fri, 2010-07-16 at 20:41 +0200, Andres Freund wrote: > You argue above that you cant change SET [NOT] NULL to be less > restrictive because it might change plans - isnt that true for some of the > above cases as well? > > For example UNIQUE/PRIMARY might make join removal possible - which could > only be valid after "invalid" tuples where deleted earlier in that > transaction. Another case which it influences are grouping plans... This is only for adding a constraint, not removing it. Join removal would be possible after the ALTER finishes, but won't change plans already in progress. The idea is to minimise the impact, not maximise the benefit of the newly added constraint; I don't think we should block all queries just because a few might benefit. > So I think the only case where its actually possible to lower the > level is CONSTR_EXCLUSION and _FOREIGN. > The latter might get impossible soon by planner improvements (Peter's > functional dependencies patch for example). Same, I don't see why it would block queries. -- Simon Riggs www.2ndQuadrant.comPostgreSQL Development, 24x7 Support, Training and Services
В списке pgsql-hackers по дате отправления: