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 по дате отправления:

Предыдущее
От: Thomas Munro
Дата:
Сообщение: Re: POC: Cleaning up orphaned files using undo logs
Следующее
От: Evgeniy Efimkin
Дата:
Сообщение: Re: [WIP] CREATE SUBSCRIPTION with FOR TABLES clause (table filter)