Re: Expression errors with "FOR UPDATE" and postgres_fdw with partitionwise join enabled.

Поиск
Список
Период
Сортировка
От Etsuro Fujita
Тема Re: Expression errors with "FOR UPDATE" and postgres_fdw with partitionwise join enabled.
Дата
Msg-id 5B683F60.2070806@lab.ntt.co.jp
обсуждение исходный текст
Ответ на Re: Expression errors with "FOR UPDATE" and postgres_fdw with partitionwise join enabled.  (Etsuro Fujita <fujita.etsuro@lab.ntt.co.jp>)
Ответы Re: Expression errors with "FOR UPDATE" and postgres_fdw withpartition wise join enabled.
Список pgsql-hackers
(2018/08/03 22:28), Etsuro Fujita wrote:
> (2018/08/03 22:18), Etsuro Fujita wrote:
>> Here is a patch for refusing to generate PWJ paths when WRVs are
>> involved:
>>
>> * We no longer need to handle WRVs, so I've simplified
>> build_joinrel_tlist() and setrefs.c to what they were before
>> partition-wise join went in, as in the previous patch.
>>
>> * attr_needed data for each child is used for building child-joins'
>> tlists, but I think we can build those by applying
>> adjust_appendrel_attrs to the parent's tlists, without attr_needed. So,
>> I've also removed that as in the previous patch.
>
> One thing to add: as for the latter, we don't need the changes to
> placeholder.c either, so I've also simplified that to what they were
> before partition-wise join went in.

*** a/src/backend/optimizer/plan/planner.c
--- b/src/backend/optimizer/plan/planner.c
***************
*** 3960,3965 **** create_ordinary_grouping_paths(PlannerInfo *root, 
RelOptInfo *input_rel,
--- 3960,3967 ----
      */
     if (extra->patype != PARTITIONWISE_AGGREGATE_NONE &&
         input_rel->part_scheme && input_rel->part_rels &&
+       (input_rel->reloptkind == RELOPT_BASEREL ||
+        input_rel->consider_partitionwise_join) &&
         !IS_DUMMY_REL(input_rel))
     {
         /*
***************
*** 6913,6919 **** apply_scanjoin_target_to_paths(PlannerInfo *root,
      * projection-capable, that might save a separate Result node, and 
it also
      * is important for partitionwise aggregate.
      */
!   if (rel->part_scheme && rel->part_rels)
     {
         int         partition_idx;
         List       *live_children = NIL;
--- 6915,6923 ----
      * projection-capable, that might save a separate Result node, and 
it also
      * is important for partitionwise aggregate.
      */
!   if (rel->part_scheme && rel->part_rels &&
!       (rel->reloptkind == RELOPT_BASEREL ||
!        rel->consider_partitionwise_join))
     {
         int         partition_idx;
         List       *live_children = NIL;

In the above I used the test whether the relation's reloptkind is 
RELOPT_BASEREL or not, but I noticed that I had overlooked the case of a 
multi-level partitioned table.  So I fixed that and added regression 
test cases for that.  I also revised comments a bit.  Attached is an 
updated version of the patch.

Best regards,
Etsuro Fujita

Вложения

В списке pgsql-hackers по дате отправления:

Предыдущее
От: Ashutosh Bapat
Дата:
Сообщение: Re: TupleTableSlot abstraction
Следующее
От: Laurenz Albe
Дата:
Сообщение: Re: Loaded footgun open_datasync on Windows