From: | Heikki Linnakangas <heikki(dot)linnakangas(at)enterprisedb(dot)com> |
---|---|
To: | Robert Haas <robertmhaas(at)gmail(dot)com> |
Cc: | pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: counting pallocs |
Date: | 2012-05-17 06:28:39 |
Message-ID: | 4FB49A97.7010408@enterprisedb.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On 17.05.2012 06:43, Robert Haas wrote:
> The attached patch provides some rough instrumentation for determining
> where palloc calls are coming from. This is obviously just for
> noodling around with, not for commit, and there may well be bugs. But
> enjoy.
>
> I gave this a quick spin on a couple of test workloads: a very short
> pgbench test, a very short pgbench -S test, and the regression tests.
> On the pgbench test, the top culprits are ExecInitExpr() and
> expression_tree_mutator(); in both cases, the lappend() call for the
> T_List case is the major contributor. Other significant contributors
> include _copyVar(), which I haven't drilled into terribly far but
> seems to be coming mostly from add_vars_to_targetlist();
> buildRelationAliases() via lappend, pstrdup, and makeString;
> ExecAllocTupleTableSlot(); and makeColumnRef() via makeNode, lcons,
> and makeString.
What percentage of total CPU usage is the palloc() overhead in these
tests? If we could totally eliminate the palloc() overhead, how much
faster would the test run?
--
Heikki Linnakangas
EnterpriseDB http://www.enterprisedb.com
From | Date | Subject | |
---|---|---|---|
Next Message | Erik Rijkers | 2012-05-17 09:33:50 | master and sync-replica diverging |
Previous Message | Pavel Stehule | 2012-05-17 04:43:06 | Re: temporal support patch |