Skip site navigation (1) Skip section navigation (2)

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 (view raw or flat)
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

pgsql-hackers by date

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

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group