Greg Stark <> writes:
> On Sun, Aug 31, 2014 at 9:03 PM, Tom Lane <> wrote:
>> Aside from costing planning time, most likely that would forever prevent
>> us from pushing some types of intelligence about partitioning into the
>> executor.

> How would it affect this calculus if there were partitioned indexes
> which were created on the overall table and guaranteed to exist on
> each partition that the planner could use -- and then possibly also
> per-partition indexes that might exist in addition to those?

That doesn't actually fix the planning-time issue at all.  Either the
planner considers each partition individually to create a custom plan
for it, or it doesn't.

The "push into executor" idea I was alluding to is that we might invent
plan constructs like a ModifyTable node that applies to a whole
inheritance^H^H^Hpartitioning tree and leaves the tuple routing to be
done at runtime.  You're not going to get a plan structure like that
if the planner is building a separate plan subtree for each partition.

                        regards, tom lane

Sent via pgsql-hackers mailing list (
To make changes to your subscription:

Reply via email to