Re: Storing hot members of PGPROC out of the band - Mailing list pgsql-hackers

From Robert Haas
Subject Re: Storing hot members of PGPROC out of the band
Date
Msg-id CA+TgmoZvpj1RfLu92MdTtvd44bqO56yT6-yo2_WuHQP+z=UxoQ@mail.gmail.com
Whole thread Raw
In response to Re: Storing hot members of PGPROC out of the band  (Heikki Linnakangas <heikki.linnakangas@enterprisedb.com>)
Responses Re: Storing hot members of PGPROC out of the band
List pgsql-hackers
On Mon, Nov 7, 2011 at 6:45 AM, Heikki Linnakangas
<heikki.linnakangas@enterprisedb.com> wrote:
> Agreed, that seems more clean. The PGPROCs for prepared transactions are
> currently allocated separately, so they're not currently in the same array
> as all other PGPROCs, but that could be changed. Here's a WIP patch for
> that. I kept the PGPROC_MINIMAL nomenclature for now, but I agree with
> Simon's suggestion to rename it.

All right, I did that in the attached version, using Simon's suggested
name.  I also fixed up various comments (especially in
InitProcGlobal), fixed the --enable-cassert build (which was busted),
and added code to save/restore PreparedXactProcs in EXEC_BACKEND mode
(which I assume is necessary, though the regression tests failed to
fail without it).

I'm wondering about the changes to how globalxmin is computed in
GetSnapshotData().  That seems like it could hurt performance in the
single-client case, and especially in the case where there is one
active connection and lots of idle connections, and I'm wondering how
thoroughly we've tested that particular bit apart from these other
changes.

--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company

Attachment

pgsql-hackers by date:

Previous
From: Jeff Davis
Date:
Subject: Re: Singleton range constructors versus functional coercion notation
Next
From: Alvaro Herrera
Date:
Subject: Re: strange nbtree corruption report