counting pallocs - Mailing list pgsql-hackers

From Robert Haas
Subject counting pallocs
Date
Msg-id CA+TgmoaC86O27z9D+5VcK5GhJu_eR9bYm_mse+zuic7UVyAxEA@mail.gmail.com
Whole thread Raw
Responses Re: counting pallocs
Re: counting pallocs
List pgsql-hackers
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.

The pgbench -S results are similar, but build_physical_tlist() also
pops up fairly high.

On the regression tests, heap_tuple_untoast_attr() is at the very top
of the list, and specifically for the VARATT_IS_SHORT() case.  It
might be good to disaggregate this some more, but I'm too tired for
that right now.  index_form_tuple()'s palloc0 call comes in second,
and heap_form_minimal_tuple()'s palloc0 is third.
LockAcquireExtended()'s allocation of a new LOCALLOCK entry also comes
in prettyhigh; ExecInitExpr() shows up here too; and heap_form_tuple()
shows up as well.

One piece of reasonably low-hanging fruit appears to be OpExpr.  It
seems like it would be better all around to put Node *arg1 and Node
*arg2 in there instead of a list...  aside from saving pallocs, it
seems like it would generally simplify the code.

--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company

Attachment

pgsql-hackers by date:

Previous
From: Alvaro Herrera
Date:
Subject: Re: "could not open relation with OID" errors after promoting the standby to master
Next
From: Pavel Stehule
Date:
Subject: Re: temporal support patch