Joe Conway <[EMAIL PROTECTED]> writes: > This patch retains the memory consumption savings but doesn't break any > regression tests...
I'm unconvinced that retail pfree's are the way to go. I just did some profiling of this test case: insert into foo values (0,0,0), (1,1,1), (2,2,2), (3,3,3), ... one million rows ... (999997,999997,999997), (999998,999998,999998), (999999,999999,999999); using CVS tip, and got these oprofile results: samples % symbol name 39742 10.1656 base_yyparse 38338 9.8065 XLogInsert 28247 7.2253 AllocSetAlloc 20490 5.2411 expression_tree_walker 16822 4.3029 ExecInitExpr 16469 4.2126 base_yylex 14789 3.7829 PageAddItem 11174 2.8582 LWLockAcquire 11167 2.8564 LWLockRelease 9195 2.3520 RewriteQuery 9120 2.3328 AllocSetFree 7788 1.9921 ExecInitValuesScan 7596 1.9430 ExecEvalConst 7586 1.9404 lappend 6860 1.7547 ValuesNext 6261 1.6015 heap_fill_tuple 6141 1.5708 MemoryContextAllocZeroAligned 5619 1.4373 fix_expr_references_walker 5613 1.4357 transformExpressionList 5269 1.3478 heap_insert 5177 1.3242 contain_vars_of_level_walker 4601 1.1769 heap_form_tuple 4345 1.1114 ExecutorRun 4299 1.0996 hash_any 4201 1.0746 MemoryContextAlloc 4061 1.0388 check_stack_depth It's slightly depressing that there's not more time being spent in places we can easily tweak, but anyway the salient point to me is that AllocSetFree is already chewing a nontrivial part of the runtime. regards, tom lane ---------------------------(end of broadcast)--------------------------- TIP 4: Have you searched our list archives? http://archives.postgresql.org