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

From: wieck(at)debis(dot)com (Jan Wieck)
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Jan Wieck <wieck(at)debis(dot)com>, Karel Zak - Zakkr <zakkr(at)zf(dot)jcu(dot)cz>, Hiroshi Inoue <Inoue(at)tpf(dot)co(dot)jp>, pgsql-hackers <pgsql-hackers(at)postgreSQL(dot)org>
Subject: Re: [HACKERS] Cache query (PREPARE/EXECUTE)
Date: 2000-02-24 00:16:31
Message-ID: m12NlxH-0003ksC@orion.SAPserv.Hamburg.dsh.de
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Tom Lane wrote:

> wieck(at)debis(dot)com (Jan Wieck) writes:
> > OTOH, this new per-object-context stuff could hand down some
> > lifetime flag, let's say MCXT_UNTIL_STATEMENT, MCXT_UTIL_XEND
> > and MCXT_UNTIL_INFINITY to start from.
>
> A good thing to keep in mind, but for the short term I'm not sure
> we need it; the proposed new contexts are all for indefinite-lifetime
> caches, so there's no chance to make them go away automatically.
> Eventually we might have more uses for limited-lifetime contexts,
> though.

Sure, was only what I thought might be useful in some cases.
If not used, would it hurt to have support for it either?
Some unused List*'ers somewhere - nothing important.

> Something else that needs to be looked at is how memory contexts
> are tied to "portals" presently. That mechanism probably needs
> to be redesigned. I have to admit I don't understand what it's
> for...

U2? Makes 2 of us.

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

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Rolf Grossmann 2000-02-24 00:53:12 Re: [BUGS] First experiences with Postgresql 7.0
Previous Message Roberto Cornacchia 2000-02-24 00:10:36 Re: about 7.0 LIMIT optimization