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

Tom Lane <tgl@sss.pgh.pa.us>

From: Tom Lane <tgl@sss.pgh.pa.us>
To: Andres Freund <andres@2ndquadrant.com>
Cc: Heikki Linnakangas <hlinnakangas@vmware.com>, pgsql-hackers@postgresql.org
Date: 2013-01-09T20:43:19Z
Lists: pgsql-hackers
I wrote:
> I then applied the palloc.h and mcxt.c hunks of your patch and rebuilt.
> Now I get an average runtime of 16666 ms, a full 2% faster, which is a
> bit astonishing, particularly because the oprofile results haven't moved
> much:

I studied the assembly code being generated for palloc(), and I believe
I see the reason why it's a bit faster: when there's only a single local
variable that has to survive over the elog call, gcc generates a shorter
function entry/exit sequence.  I had thought of proposing that we code
palloc() like this:

void *
palloc(Size size)
{
    MemoryContext context = CurrentMemoryContext;

    AssertArg(MemoryContextIsValid(context));

    if (!AllocSizeIsValid(size))
        elog(ERROR, "invalid memory alloc request size %lu",
             (unsigned long) size);

    context->isReset = false;

    return (*context->methods->alloc) (context, size);
}

but at least on this specific hardware and compiler that would evidently
be a net loss compared to direct use of CurrentMemoryContext.  I would
not put a lot of faith in that result holding up on other machines
though.

In any case this doesn't explain the whole 2% speedup, but it probably
accounts for palloc() showing as slightly cheaper than
MemoryContextAlloc had been in the oprofile listing.

			regards, tom lane


Commits

  1. Prevent creation of postmaster's TCP socket during pg_upgrade testing.