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
Re: speeding up planning with partitions |
Список | 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 по дате отправления: