Re: Parallel INSERT (INTO ... SELECT ...)

Поиск
Список
Период
Сортировка
От Greg Nancarrow
Тема Re: Parallel INSERT (INTO ... SELECT ...)
Дата
Msg-id CAJcOf-fkoCt_3eo0Q0LsLrY=5M1z=tN4HyWWsyKLDF_-d_J0Tg@mail.gmail.com
обсуждение исходный текст
Ответ на RE: Parallel INSERT (INTO ... SELECT ...)  ("Hou, Zhijie" <houzj.fnst@cn.fujitsu.com>)
Ответы RE: Parallel INSERT (INTO ... SELECT ...)  ("Hou, Zhijie" <houzj.fnst@cn.fujitsu.com>)
RE: Parallel INSERT (INTO ... SELECT ...)  ("Hou, Zhijie" <houzj.fnst@cn.fujitsu.com>)
Список pgsql-hackers
On Mon, Jan 25, 2021 at 10:40 PM Hou, Zhijie <houzj.fnst@cn.fujitsu.com> wrote:
>
> Hi,
>
> When reading the code of rel_max_parallel_hazard_for_modify in 0001.
>
> I thought there are so many places call table_close().
> Personally, It's a little confused to me.
>
> Do you think it's better to do the table_open/close outside of rel_max_parallel_hazard_for_modify ?
>
> Like:
>
> static bool rel_max_parallel_hazard_for_modify(Relation rel,
>                                                CmdType command_type,
>                                                max_parallel_hazard_context *context);
> ...
>         Relation relation = table_open(rte->relid, NoLock);
>         (void) rel_max_parallel_hazard_for_modify(relation, parse->commandType, &context);
>         table_close(relation, NoLock);
>
>
> And we seems do not need the lockmode param with the above define.
>
>

Yeah, the repeated cleanup at the point of return is a bit ugly.
It could be solved by changing the function to do cleanup at a common
return point, but I agree with you that in this case it could simply
be done outside the function.
Thanks, I'll make that change.

Regards,
Greg Nancarrow
Fujitsu Australia



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

Предыдущее
От: Michael Paquier
Дата:
Сообщение: Add SQL function for SHA1
Следующее
От: Konstantin Knizhnik
Дата:
Сообщение: Re: Columns correlation and adaptive query optimization