Re: Storing hot members of PGPROC out of the band

From: Robert Haas <robertmhaas(at)gmail(dot)com>
To: Heikki Linnakangas <heikki(dot)linnakangas(at)enterprisedb(dot)com>
Cc: Simon Riggs <simon(at)2ndquadrant(dot)com>, Pavan Deolasee <pavan(dot)deolasee(at)gmail(dot)com>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Storing hot members of PGPROC out of the band
Date: 2011-11-22 17:35:01
Message-ID: CA+TgmoZvpj1RfLu92MdTtvd44bqO56yT6-yo2_WuHQP+z=UxoQ@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Mon, Nov 7, 2011 at 6:45 AM, Heikki Linnakangas
<heikki(dot)linnakangas(at)enterprisedb(dot)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 Content-Type Size
pgxact.patch application/octet-stream 54.2 KB

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2011-11-22 18:01:23 Re: Singleton range constructors versus functional coercion notation
Previous Message Alvaro Herrera 2011-11-22 17:23:17 Re: strange nbtree corruption report