Re: speeding up planning with partitions
От | Jesper Pedersen |
---|---|
Тема | Re: speeding up planning with partitions |
Дата | |
Msg-id | d768d90d-628e-6cdc-513d-f50a0ce02cea@redhat.com обсуждение исходный текст |
Ответ на | Re: speeding up planning with partitions (Amit Langote <Langote_Amit_f8@lab.ntt.co.jp>) |
Ответы |
Re: speeding up planning with partitions
|
Список | pgsql-hackers |
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
Вложения
В списке pgsql-hackers по дате отправления: