RE: Parallel INSERT (INTO ... SELECT ...) - Mailing list pgsql-hackers

From Hou, Zhijie
Subject RE: Parallel INSERT (INTO ... SELECT ...)
Date
Msg-id 6f73f94e7e4e4e66be18a474d4b5a625@G08CNEXMBPEKD05.g08.fujitsu.local
Whole thread Raw
In response to Re: Parallel INSERT (INTO ... SELECT ...)  (Greg Nancarrow <gregn4422@gmail.com>)
Responses Re: Parallel INSERT (INTO ... SELECT ...)
RE: Parallel INSERT (INTO ... SELECT ...)
List 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 by date:

Previous
From: Tomas Vondra
Date:
Subject: Re: WIP: BRIN multi-range indexes
Next
From: Peter Geoghegan
Date:
Subject: Re: vacuum_cost_page_miss default value and modern hardware