Hi Amit,
On 3/12/19 4:22 AM, Amit Langote wrote:
I wrestled with this idea a bit and concluded that we don't have to
postpone *all* of preprocess_targetlist() processing to query_planner,
only the part that adds row mark "junk" Vars, because only those matter
for the problem being solved. To recap, the problem is that delaying
adding inheritance children (and hence their row marks if any) means we
can't add "junk" columns needed to implement row marks, because which ones
to add is not clear until we've seen all the children.
I propose that we delay the addition of "junk" Vars to query_planner() so
that it doesn't stand in the way of deferring inheritance expansion to
query_planner() too. That means the order of reltarget expressions for
row-marked rels will change, but I assume that's OK. At least it will be
consistent for both non-inherited baserels and inherited ones.
Attached updated version of the patches with the above proposal
implemented by patch 0002. To summarize, the patches are as follows:
0001: make building of "other rels" a separate step that runs after
deconstruct_jointree(), implemented by a new subroutine of query_planner
named add_other_rels_to_query()
0002: delay adding "junk" Vars to after add_other_rels_to_query()
0003: delay inheritance expansion to add_other_rels_to_query()
0004, 0005: adjust inheritance_planner() to account for the fact that
inheritance is now expanded by query_planner(), not subquery_planner()
0006: perform partition pruning while inheritance is being expanded,
instead of during set_append_append_rel_size()
0007: add a 'live_parts' field to RelOptInfo to store partition indexes
(not RT indexes) of unpruned partitions, which speeds up looping over
part_rels array of the partitioned parent
0008: avoid copying PartitionBoundInfo struct for planning
After applying 0004 check-world fails with the attached. CFBot agrees [1].
[1] https://travis-ci.org/postgresql-cfbot/postgresql/builds/505107884
Best regards,
Jesper
diff -U3
/home/jpedersen/PostgreSQL/postgresql/contrib/postgres_fdw/expected/postgres_fdw.out
/home/jpedersen/PostgreSQL/postgresql/contrib/postgres_fdw/results/postgres_fdw.out
---
/home/jpedersen/PostgreSQL/postgresql/contrib/postgres_fdw/expected/postgres_fdw.out
2019-03-12 07:46:08.430690229 -0400
+++
/home/jpedersen/PostgreSQL/postgresql/contrib/postgres_fdw/results/postgres_fdw.out
2019-03-12 07:59:01.134285159 -0400
@@ -7190,8 +7190,8 @@
-- Check UPDATE with inherited target and an inherited source table
explain (verbose, costs off)
update bar set f2 = f2 + 100 where f1 in (select f1 from foo);
- QUERY PLAN
----------------------------------------------------------------------------------------------
+ QUERY PLAN
+---------------------------------------------------------------------------------------
Update on public.bar
Update on public.bar
Foreign Update on public.bar2
@@ -7214,22 +7214,22 @@
Output: foo2.f1, foo2.ctid, foo2.*,
foo2.tableoid
Remote SQL: SELECT f1, f2, f3, ctid FROM
public.loct1
-> Hash Join
- Output: bar2.f1, (bar2.f2 + 100), bar2.f3, bar2.ctid, foo.ctid,
foo.*, foo.tableoid
+ Output: bar2.f1, (bar2.f2 + 100), bar2.f3, bar2.ctid, foo.ctid, foo.*
Inner Unique: true
Hash Cond: (bar2.f1 = foo.f1)
-> Foreign Scan on public.bar2
Output: bar2.f1, bar2.f2, bar2.f3, bar2.ctid
Remote SQL: SELECT f1, f2, f3, ctid FROM public.loct2 FOR UPDATE
-> Hash
- Output: foo.f1, foo.ctid, foo.*, foo.tableoid
+ Output: foo.f1, foo.ctid, foo.*
-> HashAggregate
- Output: foo.f1, foo.ctid, foo.*, foo.tableoid
+ Output: foo.f1, foo.ctid, foo.*
Group Key: foo.f1
-> Append
-> Seq Scan on public.foo
- Output: foo.f1, foo.ctid, foo.*, foo.tableoid
+ Output: foo.f1, foo.ctid, foo.*
-> Foreign Scan on public.foo2
- Output: foo2.f1, foo2.ctid, foo2.*,
foo2.tableoid
+ Output: foo2.f1, foo2.ctid, foo2.*
Remote SQL: SELECT f1, f2, f3, ctid FROM
public.loct1
(39 rows)
