Re: Storing hot members of PGPROC out of the band

Поиск
Список
Период
Сортировка
От Robert Haas
Тема Re: Storing hot members of PGPROC out of the band
Дата
Msg-id CA+TgmoZvpj1RfLu92MdTtvd44bqO56yT6-yo2_WuHQP+z=UxoQ@mail.gmail.com
обсуждение исходный текст
Ответ на Re: Storing hot members of PGPROC out of the band  (Heikki Linnakangas <heikki.linnakangas@enterprisedb.com>)
Ответы Re: Storing hot members of PGPROC out of the band
Список 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

Вложения

В списке pgsql-hackers по дате отправления:

Предыдущее
От: Jeff Davis
Дата:
Сообщение: Re: Singleton range constructors versus functional coercion notation
Следующее
От: Alvaro Herrera
Дата:
Сообщение: Re: strange nbtree corruption report