Planned changes in backend memory management

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: pgsql-hackers(at)postgreSQL(dot)org
Subject: Planned changes in backend memory management
Date: 2003-04-30 19:14:00
Message-ID: 23737.1051730040@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

I've committed some updates in the memory management README file to
describe what I'm about to do to the backend's memory management
conventions, in support of the new FE/BE protocol's extended-query
features. You can read about it at
http://developer.postgresql.org/cvsweb.cgi/pgsql-server/src/backend/utils/mmgr/README

Briefly:

* TransactionCommandContext is going away --- it doesn't seem to have
any function once we insist that all execution is going to happen inside
portals.

* The former meaning of QueryContext is now assigned to MessageContext;
this is a context that holds the current input message from the
frontend, and is reset before accepting each new input message.

* The QueryContext global variable still exists, but no longer denotes a
single memory context. It will point to the memory context holding the
parse and plan trees for the currently-executing query --- this could be
either MessageContext or the private memory context of a
prepared-statement object. There will be only limited need to use this
variable, I expect. (PreventTransactionChain might be the only place,
in fact.)

* Analogous to QueryContext, there will be a global variable
PortalContext that points at the private context of the currently
executing portal. This can substitute for TransactionCommandContext for
places that need to allocate memory that will live for the duration of
the current command.

Comments?

regards, tom lane

Browse pgsql-hackers by date

  From Date Subject
Next Message Daniele Orlandi 2003-04-30 21:21:29 Attribute must be GROUPed.... ?
Previous Message Patrick Macdonald 2003-04-30 17:34:01 PITR: Proposed modifications to JR's design