RE: speeding up planning with partitions

Поиск
Список
Период
Сортировка
От Imai, Yoshikazu
Тема RE: speeding up planning with partitions
Дата
Msg-id 0F97FA9ABBDBE54F91744A9B37151A5127E7D2@g01jpexmbkw24
обсуждение исходный текст
Ответ на Re: speeding up planning with partitions  (Tom Lane <tgl@sss.pgh.pa.us>)
Ответы Re: speeding up planning with partitions  (Tom Lane <tgl@sss.pgh.pa.us>)
Список pgsql-hackers
On Mon, Feb 18, 2019 at 5:28 PM, Tom Lane wrote:
> 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.

When I reviewed this, I thought there are no problems in the codes, but I googled what Tom pointed out[1], read it and
Iwas ashamed of my ignorance.
 

> 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?

ISTM the 0004 patch eventually removes these codes from multiple places (set_append_rel_size and
set_inherited_target_rel_sizes)so we might be better to not be struggling here?
 

[1] https://www.teamten.com/lawrence/programming/keep-if-clauses-side-effect-free.html

--
Yoshikazu Imai


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

Предыдущее
От: Andres Freund
Дата:
Сообщение: Re: Speed up transaction completion faster after many relations areaccessed in a transaction
Следующее
От: Amit Langote
Дата:
Сообщение: Re: speeding up planning with partitions