Greg Stark <st...@mit.edu> writes:
> On Sun, Aug 31, 2014 at 9:03 PM, Tom Lane <t...@sss.pgh.pa.us> 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 (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
