Re: Re: [PATCH] unified frontend support for pg_malloc et al and palloc/pfree mulation (was xlogreader-v4)

From: Steve Singer <steve(at)ssinger(dot)info>
To: Andres Freund <andres(at)2ndquadrant(dot)com>
Cc: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Heikki Linnakangas <hlinnakangas(at)vmware(dot)com>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: Re: [PATCH] unified frontend support for pg_malloc et al and palloc/pfree mulation (was xlogreader-v4)
Date: 2013-01-21 21:59:04
Message-ID: BLU0-SMTP9664B348712E232115DE4ADC170@phx.gbl
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: 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
>
>

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Noah Misch 2013-01-21 22:43:13 Re: Teaching pg_receivexlog to follow timeline switches
Previous Message Robert Haas 2013-01-21 20:19:43 Re: Removing PD_ALL_VISIBLE