On Thu, Jan 13, 2011 at 19:00, Shigeru HANADA <hanada@metrosystems.co.jp> wrote:
> But EndCopyFrom() seems not to be able to release memory which is
> allocated in BeginCopy() and BeginCopyFrom(). I found this behavior
> by executing a query which generates nested loop plan (outer 1000000
> row * inner 10 row), and at last postgres grows up to 300MB+ from
> 108MB (VIRT of top command).
>
> Attached patch would avoid this leak by adding per-copy context to
> CopyState. This would be overkill, and ResetCopyFrom() might be
> reasonable though.
Good catch. I merged your fix into the attached patch.
BTW, why didn't planner choose a materialized plan for the inner loop?
FDW scans are typically slower than heap scans or TupleTableslot scans,
it seems reasonable for me to add a Materialize node at the top of the
inner Foreign Scan, especially when we don't use indexes for the scan
keys or join keys.
--
Itagaki Takahiro
