On Mon, 28 Jan 2019 at 20:45, Amit Langote <langote_amit...@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
