Re: ALTER TABLE SET STATISTICS requires AccessExclusiveLock

From: Simon Riggs <simon(at)2ndQuadrant(dot)com>
To: Andres Freund <andres(at)anarazel(dot)de>
Cc: pgsql-hackers(at)postgresql(dot)org
Subject: Re: ALTER TABLE SET STATISTICS requires AccessExclusiveLock
Date: 2010-07-16 19:12:33
Message-ID: 1279307553.1735.40190.camel@ebony
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: 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.com
PostgreSQL Development, 24x7 Support, Training and Services

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Simon Riggs 2010-07-16 19:15:44 Re: ALTER TABLE SET STATISTICS requires AccessExclusiveLock
Previous Message Andres Freund 2010-07-16 19:10:06 Re: ALTER TABLE SET STATISTICS requires AccessExclusiveLock