Re: [HACKERS] Runtime Partition Pruning
От | Alvaro Herrera |
---|---|
Тема | Re: [HACKERS] Runtime Partition Pruning |
Дата | |
Msg-id | 20180417023343.6fg3i7m534lstxom@alvherre.pgsql обсуждение исходный текст |
Ответ на | Re: [HACKERS] Runtime Partition Pruning (David Rowley <david.rowley@2ndquadrant.com>) |
Ответы |
Re: [HACKERS] Runtime Partition Pruning
|
Список | pgsql-hackers |
David Rowley wrote: > 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. I think trying to replace a well-placed MemoryContextReset (or Delete) with a bunch of individual pfrees is pointless. -- Álvaro Herrera https://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
В списке pgsql-hackers по дате отправления: