On 14 April 2018 at 05:04, Robert Haas <robertmh...@gmail.com> wrote: > But I wonder why it's the executor's job to clean up after the > planner, instead of adjusting the relevant planner functions to avoid > leaking memory?
It might be possible, but it might also be risky and difficult. For a while, during my review of the faster partition pruning patch I was asking Amit to add pfree() calls in various places for this exact reason, but in the end, I gave up and decided it was easier to just create a new memory context to call the planner function from. I've now forgotten the exact reason why I finally decided it was too much trouble. The pruning code now works using your step logic so perhaps that reason no longer applies, although, on a quick scan of the pruning code now, it seems to require that get_matching_partitions performs a deep pfree of each PruneStepResult. However, there is still partkey_datum_from_expr which performs ExecInitExpr, although perhaps that can just be done once, and the result stashed in the PartitionPruneContext. -- David Rowley http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Training & Services
