Re: Delay locking partitions during query execution

On Mon, 28 Jan 2019 at 20:45, Amit Langote
<Langote_Amit_f8@lab.ntt.co.jp> wrote:
> It seems to me that plancache.c doesn't really need to perform
> AcquireExecutorLocks()/LockRelationOid() to learn that a partition's
> reloptions property has changed to discard a generic plan and build a new
> one.  AFAICT, PlanCacheRelCallback() takes care of resetting a cached plan
> by observing that an invalidation message that it received  either from
> the same session or from another session belongs to one of the relations
> in PlannedStmt.relationOids.  That list must already contain all
> partitions' OIDs.

Really? So when you tried my case you properly got a plan with a
non-parallel Seq Scan on listp1?

I imagine you didn't with yours since we check for relcache
invalidations at the start of a transaction.  I performed both my
EXECUTEs in the same transaction.


-- 
 David Rowley                   http://www.2ndQuadrant.com/
 PostgreSQL Development, 24x7 Support, Training & Services