On Thu, Dec 20, 2018 at 3:58 PM Alvaro Herrera <alvhe...@2ndquadrant.com> wrote: > > Introduce the concept of a partition directory. > > > > Teach the optimizer and executor to use it, so that a single planning > > cycle or query execution gets the same PartitionDesc for the same table > > every time it looks it up. This does not prevent changes between > > planning and execution, nor does it guarantee that all tables are > > expanded according to the same snapshot. > > Namely: how does this handle the case of partition pruning structure > being passed from planner to executor, if an attach happens in the > middle of it and puts a partition in between existing partitions? Array > indexes of any partitions that appear later in the partition descriptor > will change. > > This is the reason I used the query snapshot rather than EState.
I didn't handle that. If partition pruning relies on nothing changing between planning and execution, isn't that broken regardless of any of this? It's true that with the simple query protocol we'll hold locks continuously from planning into execution, and therefore with the current locking regime we couldn't really have a problem. But unless I'm confused, with the extended query protocol it's quite possible to generate a plan, release locks, and then reacquire locks at execution time. Unless we have some guarantee that a new plan will always be generated if any DDL has happened in the middle, I think we've got trouble, and I don't think that is guaranteed in all cases. Maybe I'm all wet, though. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company
