From: | wieck(at)debis(dot)com (Jan Wieck) |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | Hiroshi Inoue <Inoue(at)tpf(dot)co(dot)jp>, Karel Zak - Zakkr <zakkr(at)zf(dot)jcu(dot)cz>, pgsql-hackers <pgsql-hackers(at)postgreSQL(dot)org> |
Subject: | Re: [HACKERS] Cache query (PREPARE/EXECUTE) |
Date: | 2000-02-23 18:22:16 |
Message-ID: | m12NgQS-0003kgC@orion.SAPserv.Hamburg.dsh.de |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
> "Hiroshi Inoue" <Inoue(at)tpf(dot)co(dot)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(at)debis(dot)com (Jan Wieck) #
From | Date | Subject | |
---|---|---|---|
Next Message | Karel Zak - Zakkr | 2000-02-23 18:48:25 | RE: [HACKERS] Cache query (PREPARE/EXECUTE) |
Previous Message | Hiroshi Inoue | 2000-02-23 17:34:04 | RE: [HACKERS] Cache query (PREPARE/EXECUTE) |