On Thu, May 17, 2012 at 2:28 AM, Heikki Linnakangas
<heikki.linnakangas@enterprisedb.com> wrote:
> 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?
AllocSetAlloc is often the top CPU consumer in profiling results, but
it's typically only in the single-digit percentages. However, there's
also some distributed overhead that's more difficult to measure. For
example, the fact that OpExpr uses a List instead of directly pointing
to its arguments costs us three pallocs - plus three more if we ever
copy it - but it also means that accessing the first element of an
OpExpr requires three pointer dereferences instead of one, and
accessing the second one requires four pointer dereferences instead of
one. There's no real way to isolate the overhead of that, but it's
got to cost at least something.
The reality - I'm not sure whether it's a happy reality or a sad
reality - is that most CPU profiles of PostgreSQL are pretty flat.
The nails that stick up have, for the most part, long since been
pounded down. If we want to make further improvements to our parse
and plan time, and I do, because I think we lag our competitors, then
I think this is the kind of stuff we need to look at.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company