Re: [HACKERS] Cache query (PREPARE/EXECUTE)

Jan Wieck <wieck@debis.com>

From: wieck@debis.com (Jan Wieck)
To: Tom Lane <tgl@sss.pgh.pa.us>
Cc: Hiroshi Inoue <Inoue@tpf.co.jp>, Karel Zak - Zakkr <zakkr@zf.jcu.cz>, pgsql-hackers <pgsql-hackers@postgreSQL.org>
Date: 2000-02-23T18:22:16Z
Lists: pgsql-hackers
> "Hiroshi Inoue" <Inoue@tpf.co.jp> writes:
> > I think so.  The problem is that Node struct couldn't be freed safely
> > due to the lack of reference count in its definition.  As far as I see
> > plans could be destroyed only when the memory context in which
> > they are placed are destroyed.
>
> This is overly conservative.  It should be safe to destroy a plan tree
> via freeObject() if it was created via copyObject() --- and that is
> certainly how the plan would get into a permanent memory context.
>
> Currently, rule definitions are leaked in CacheContext at relcache
> flushes.  I plan to start freeing them via freeObject at the beginning
> of the 7.1 development cycle --- I didn't want to risk it during the
> runup to 7.0, but I believe it will work fine.

    I  don't  see  any  reason,  why  each  saved  plan  or  rule
    definition  shouldn't  go  into  it's  own,  private   memory
    context.  Then,  a  simple  destruction of the entire context
    will surely free all it's memory, and I think it will also be
    faster  since  the  en-block  allocation, done for many small
    objects, doesn't need to free all them separately - it throws
    away  the  entire  blocks. No need to traverse the node tree,
    nor any problems with multiple object references  inside  the
    tree.

    Since  plans  are (ought to be) saved via SPI_saveplan(plan),
    there is already a central point where it  can  be  done  for
    plans.  And a corresponding SPI_freeplan(savedplan) should be
    easy to create, since the context can be held in the SPI plan
    structure itself.

    Needs  only  some  general naming convention for these memory
    contexts.  But something like a

        MemoryContext CreateObjectMemoryContext();

    that  guarantees  uniqueness  in  the  context  name  and  no
    conflicts  by using some appropriate prefix in them should do
    it.

    The overhead, payed for separate contexts is IMHO negligible.


Jan

--

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