Re: [HACKERS] Postgres Speed or lack thereof

jwieck@debis.com (Jan Wieck) writes:
> Tom Lane wrote:
>> However, we probably don't really want to touch each individual palloc()
>> call in the system ...

>     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).

Much less than I thought, also.  And (grep|wc...) over 300 of these
calls are in the utils/adt code, ie, they are for passing back the
results of type conversion functions.  We'll only need to think through
how that should work once, and then it's just a mechanical edit to all
the ADT files.

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

OK, I agree.

>     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.

What about my prior point that the bottom-level function may not know
how long the caller needs the storage?  Will we have to add a "memory
context to put result in" parameter to a lot of routines?  Ugh, but
maybe it's the only way.

I've noticed that everyone else contributing to this thread has been
thinking in terms of inventing multiple allocation functions with
different names, ie a routine might have to call "palloc" or
"fast_palloc" or "tmp_palloc" or whatever depending on what behavior it
wants.  I really think we are better off to stick to the structure that
we already have (cf. include/nodes/memnodes.h and include/utils/mcxt.h),
in which there's one set of interface routines that take a "context"
parameter, and the context determines the semantics of allocation.
(The interface routines probably ought to be macros, not out-of-line
code, but that's a minor optimization.)  This will make it easier to
handle cases where one routine has to tell another one how to allocate
its result space: you pass a MemoryContext parameter.
        regards, tom lane