Re: [HACKERS] Cache query (PREPARE/EXECUTE) - Mailing list pgsql-hackers

From Tom Lane
Subject Re: [HACKERS] Cache query (PREPARE/EXECUTE)
Date
Msg-id 5824.951345647@sss.pgh.pa.us
Whole thread Raw
In response to Re: [HACKERS] Cache query (PREPARE/EXECUTE)  (wieck@debis.com (Jan Wieck))
Responses Re: [HACKERS] Cache query (PREPARE/EXECUTE)
List pgsql-hackers
wieck@debis.com (Jan Wieck) writes:
>     But I think one context per plan is still better, since first
>     there is no leakage/multiref  problem.  Second,  there  is  a
>     performance   difference   between   explicitly   pfree()'ing
>     hundreds of small allocations (in freeObject() traverse), and
>     just  destroying  a  context.

Agreed, though one would hope that performance of cache flushes
is not a major consideration ;-).

What I find attractive about going in this direction is the idea
that we could get rid of freeObject() entirely, and eliminate that
part of the work involved in changing node definitions.

>     Then  again,  copyObject/freeObject   must   be   fixed   WRT
>     leakage/multiref anyway.

Not if we decide to get rid of freeObject, instead.

I think that a little work would have to be done to support efficient
use of large numbers of contexts, but it's certainly doable.  This
path seems more attractive than trying to make the world safe for
freeObject of arbitrary node trees.
        regards, tom lane


pgsql-hackers by date:

Previous
From: "Ross J. Reedstrom"
Date:
Subject: Re: [HACKERS] Re: Feature Request
Next
From: Tom Lane
Date:
Subject: Re: [HACKERS] interesting observatation regarding views and V7.0