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(at)debis(dot)com (Jan Wieck) #