Re: speeding up planning with partitions

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: speeding up planning with partitions
Дата
Msg-id 30972.1550510855@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Re: speeding up planning with partitions  (Amit Langote <Langote_Amit_f8@lab.ntt.co.jp>)
Ответы RE: speeding up planning with partitions  ("Imai, Yoshikazu" <imai.yoshikazu@jp.fujitsu.com>)
Re: speeding up planning with partitions  (Amit Langote <Langote_Amit_f8@lab.ntt.co.jp>)
Список pgsql-hackers
Amit Langote <Langote_Amit_f8@lab.ntt.co.jp> writes:
> [ v22 patch set ]

I started to look at this, and immediately choked on the 0001 patch:

        if (childpruned ||
            !apply_child_basequals(root, rel, childrel, childRTE, appinfo) ||
            relation_excluded_by_constraints(root, childrel, childRTE))
        {

Frankly, that code is just horrid.  Having a function with side effects
in an if-test is questionable at the best of times, and having it be
the second of three conditions (which the third condition silently depends
on) is unreadable and unmaintainable.

I think the existing code here is considerably cleaner than what this
patch proposes.

I suppose you are doing this because you intend to jam some additional
cleanup code into the successfully-pruned-it code path, but if said
code is really too bulky to have multiple copies of, couldn't you
put it into a subroutine?  You're not going to be able to get to only
one copy of such cleanup anyhow, because there is another early-exit
further down, for the case where set_rel_size detects dummy-ness.

            regards, tom lane


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

Предыдущее
От: Stephen Frost
Дата:
Сообщение: Re: WAL insert delay settings
Следующее
От: Tom Lane
Дата:
Сообщение: Re: 2019-03 CF Summary / Review - Tranche #2