RE: Parallel INSERT (INTO ... SELECT ...)
От | Hou, Zhijie |
---|---|
Тема | RE: Parallel INSERT (INTO ... SELECT ...) |
Дата | |
Msg-id | 6f73f94e7e4e4e66be18a474d4b5a625@G08CNEXMBPEKD05.g08.fujitsu.local обсуждение исходный текст |
Ответ на | Re: Parallel INSERT (INTO ... SELECT ...) (Greg Nancarrow <gregn4422@gmail.com>) |
Ответы |
Re: Parallel INSERT (INTO ... SELECT ...)
RE: Parallel INSERT (INTO ... SELECT ...) |
Список | pgsql-hackers |
> > > > + > > + index_oid_list = RelationGetIndexList(rel); > > ... > > > > As memtioned in the comments of RelationGetIndexList: > > * we return a copy of the list palloc'd in the caller's context. The > > caller > > * may list_free() the returned list after scanning it. > > > > Shall we list_free(index_oid_list) at the end of function ? > > Just to avoid potential memory leak. > > > > I think that's a good idea, so I'll make that update in the next version > of the patch. > I do notice, however, that there seems to be quite a few places in the Postgres > code where RelationGetIndexList() is being called without a corresponding > list_free() being called - obviously instead relying on it being deallocated > when the caller's memory-context is destroyed. > Yes, it will be deallocated when the caller's memory-context is destroyed. Currently, parallel safety-check check each partition. I am just a little worried about if there are lots of partition here, it may cause high memory use. And there is another place like this: 1. + conbin = TextDatumGetCString(val); + check_expr = stringToNode(conbin); It seems we can free the cobin when not used(for the same reason above). What do you think ? Best regards, houzj
В списке pgsql-hackers по дате отправления: