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 ...)
RE: Parallel INSERT (INTO ... SELECT ...) |
Список | 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 по дате отправления: