Re: Parallel bitmap heap scan

On Mon, Feb 20, 2017 at 5:55 AM, Thomas Munro
<thomas(dot)munro(at)enterprisedb(dot)com> wrote:
> On Sun, Feb 19, 2017 at 9:59 PM, Dilip Kumar <dilipbalaut(at)gmail(dot)com> wrote:
>> So basically, what I want to propose is that Only during
>> ExecReScanBitmapHeapScan we can free all the DSA pointers because at
>> that time we can be sure that all the workers have completed there
>> task and we are safe to free. (And we don't free any DSA memory at
>> ExecEndBitmapHeapScan).
>
> I think this works.

OK.

> Some hand-wavy thoughts on this topic in the context of hash joins:
>
> The argument for cleaning up sooner rather than later would be that it
> could reduce the total peak memory usage of large execution plans. Is
> that a reasonable goal and can we achieve it? I suspect the answer is
> yes in theory but no in practice, and we don't even try to achieve it
> in non-parallel queries as far as I know.

We're pretty stupid about causing nodes to stop eating up resources as
early as we could; for example, when a Limit is filled, we don't make
any attempt to have scans underneath it release pins or memory or
anything else. But we don't usually let the same node consume memory
multiple times. ExecReScanBitmapHeapScan frees all of the memory used
for the previous bitmap in the non-parallel case, so it should
probably do that in the parallel case also.

--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company