Re: [HACKERS] Postgres Speed or lack thereof

Tom Lane wrote:

> However, we probably don't really want to touch each individual palloc()
> call in the system to change it to a MemoryContextAlloc(some-context, size)
> call.  Not only would that be horribly tedious, but an awful lot of
> these calls are made for the purpose of creating an object that the
> requesting routine intends to pass back to its caller.  In that
> situation, the requesting routine doesn't really *know* what the
> lifetime of the storage needs to be --- it's the caller that determines
> what's going to happen.

    There are about 900 calls of palloc() in the backend code. It
    is much less than I expected (we have over 200,000  lines  of
    code).

    So I vote for doing it ONCE HIGH QUALITY, instead of half way
    but easy to do.

    And I don't think you could avoid at least  looking  at  each
    individual  palloc().  You  defined  nesting levels, where at
    their end the allocated memory get's free'd.  But  there  are
    many  places  where  deeper  nested functions put things into
    structures that are  held  in  upper  levels  and  thus  live
    longer.  These  upper  levels  continue to use the things the
    callee's placed in there.


Jan


--

#======================================================================#
# It's easier to get forgiveness for being wrong than for being right. #
# Let's break this rule - forgive me.                                  #
#======================================== jwieck@debis.com (Jan Wieck) #