Re: Re: [PATCH] unified frontend support for pg_malloc et al and palloc/pfree mulation (was xlogreader-v4)
От | Steve Singer |
---|---|
Тема | Re: Re: [PATCH] unified frontend support for pg_malloc et al and palloc/pfree mulation (was xlogreader-v4) |
Дата | |
Msg-id | BLU0-SMTP9664B348712E232115DE4ADC170@phx.gbl обсуждение исходный текст |
Ответ на | Re: Re: [PATCH] unified frontend support for pg_malloc et al and palloc/pfree mulation (was xlogreader-v4) (Andres Freund <andres@2ndquadrant.com>) |
Список | pgsql-hackers |
On 13-01-21 12:15 PM, Andres Freund wrote: > On 2013-01-21 11:59:18 -0500, Steve Singer wrote: >> On 13-01-21 02:28 AM, Andres Freund wrote: >>> I haven't removed it from the patch afaik, so it would be great to get a >>> profile here! Its "only" for xlogdump, but that tool helped me immensely >>> and I don't want to maintain it independently... >> Here is the output from tprof >> >> Here is the baseline: > Any chance to do the test ontop of HEAD? The elog stuff has gone in only > afterwards and might actually effect this enough to be relevant. HEAD(:fb197290) Average: 28877 .AllocSetAlloc 1442 1.90 aset.c 3a938 4b0 .base_yyparse 1220 1.61 gram.c fdbc0 168ec .MemoryContextAlloc 485 0.64 mcxt.c 3a154 e0 .core_yylex 407 0.54 gram.c fab30 1c90 .AllocSetFree 320 0.42 aset.c 3b318 1b0 .MemoryContextAllocZero 316 0.42 mcxt.c 3a364 f0 .grouping_planner 271 0.36 planner.c 2b0ce8 1d10 .strncpy 256 0.34 strncpy.s b8ca0 130 .expression_tree_walker 222 0.29 nodeFuncs.c 4f734 750 ._SPI_execute_plan 221 0.29 spi.c 2fb230 840 .SearchCatCache 182 0.24 catcache.c 7d870 550 .GetSnapshotData 161 0.21 procarray.c 68acc 460 .fmgr_info_cxt_security 155 0.20 fmgr.c 3e130 850 .pfree 152 0.20 mcxt.c 39d84 70 .expression_tree_mutator 151 0.20 nodeFuncs.c 51c84 1170 .check_stack_depth 142 0.19 postgres.c 5523c 100 .text 126 0.17 parse_collate.c 233d90 1 .transformStmt 125 0.16 analyze.c 289e88 12c0 .ScanKeywordLookup 123 0.16 kwlookup.c f7ab4 154 .new_list 120 0.16 list.c 40f74 b0 .subquery_planner 115 0.15 planner.c 2b29f8 dc0 .GetCachedPlan 115 0.15 plancache.c cdab0 310 .ExecInitExpr 114 0.15 execQual.c 17e690 15f0 .set_plan_refs 113 0.15 setrefs.c 252630 cb0 .standard_ExecutorStart 110 0.14 execMain.c 1d9264 940 .heap_form_tuple 107 0.14 heaptuple.c 177c84 2f0 .query_tree_walker 105 0.14 nodeFuncs.c 4f474 210 HEAD + patch: Average: 29035 Total Ticks For All Processes (./postgres_perftest) = 15044 Subroutine Ticks % Source Address Bytes ========== ===== ====== ====== ======= ===== .AllocSetAlloc 1422 1.64 aset.c 3a938 4b0 .base_yyparse 1201 1.38 gram.c fd1e8 167f0 .palloc 470 0.54 mcxt.c 39e04 d0 .core_yylex 364 0.42 gram.c fa198 1c60 .MemoryContextAllocZero 282 0.33 mcxt.c 3a324 f0 ._SPI_execute_plan 250 0.29 spi.c 2f8c18 840 .AllocSetFree 244 0.28 aset.c 3b318 1b0 .strncpy 234 0.27 strncpy.s b86a0 130 .expression_tree_walker 229 0.26 nodeFuncs.c 4f698 750 .grouping_planner 176 0.20 planner.c 2aea84 1d30 .SearchCatCache 170 0.20 catcache.c 7d638 550 .GetSnapshotData 168 0.19 procarray.c 68904 460 .assign_collations_walker 155 0.18 parse_collate.c 231f4c 7e0 .subquery_planner 141 0.16 planner.c 2b07b4 dc0 .fmgr_info_cxt_security 141 0.16 fmgr.c 3e110 850 .check_stack_depth 140 0.16 postgres.c 550a0 100 .ExecInitExpr 138 0.16 execQual.c 17d2f8 15e0 .pfree 137 0.16 mcxt.c 39b44 70 .transformStmt 132 0.15 analyze.c 287dec 12c0 .new_list 128 0.15 list.c 40f44 90 .expression_tree_mutator 125 0.14 nodeFuncs.c 51bd8 1080 .preprocess_expression 118 0.14 planner.c 2adf54 1a0 .strcmp 118 0.14 noname 1e44 158 .standard_ExecutorStart 115 0.13 execMain.c 1d77c0 940 .MemoryContextAlloc 111 0.13 mcxt.c 3a074 e0 .set_plan_refs 109 0.13 setrefs.c 2506c4 ca0 > Otherwise I have to say I am a bit confused by the mighty difference in > costs attributed to AllocSetAlloc given the amount of calls should be > exactly the same and the number of "trampoline" function calls should > also stay the same. > Greetings, > > Andres Freund > > -- > Andres Freund http://www.2ndQuadrant.com/ > PostgreSQL Development, 24x7 Support, Training & Services > >
В списке pgsql-hackers по дате отправления: