InitProcGlobal cleanup

Поиск
Список
Период
Сортировка
Искать
От
Robert Haas
Тема
InitProcGlobal cleanup
Дата
Msg-id
BANLkTi=Di9CL4hPSE1zcdUYH_bmotb6ThQ@mail.gmail.com
Список
Дерево обсуждения
InitProcGlobal cleanup Robert Haas <robertmhaas@gmail.com>
Re: InitProcGlobal cleanup Tom Lane <tgl@sss.pgh.pa.us>
Re: InitProcGlobal cleanup Robert Haas <robertmhaas@gmail.com>
Re: InitProcGlobal cleanup Tom Lane <tgl@sss.pgh.pa.us>
Re: InitProcGlobal cleanup Robert Haas <robertmhaas@gmail.com>
9.2 branch and 9.1beta2 timing (was Re: InitProcGlobal cleanup) Tom Lane <tgl@sss.pgh.pa.us>
Re: 9.2 branch and 9.1beta2 timing (was Re: InitProcGlobal cleanup) Robert Haas <robertmhaas@gmail.com>
Re: 9.2 branch and 9.1beta2 timing (was Re: InitProcGlobal cleanup) "Kevin Grittner" <Kevin.Grittner@wicourts.gov>
Re: 9.2 branch and 9.1beta2 timing (was Re: InitProcGlobal cleanup) Robert Haas <robertmhaas@gmail.com>
While working on my patch to reduce the overhead of frequent table
locks, I had cause to monkey with InitProcGlobal() and noticed that
it's sort of a mess.  For reasons that are not clear to me, it
allocates one of the three PGPROC arrays using ShemInitStruct() and
the other two using ShmemAlloc().  I'm not clear on why we should use
different functions for different allocations, and it also seems like
it would make sense to do the whole allocation at once instead of
doing three separate ones.  Also, the setup of AuxiliaryProcs is
strangely split into two parts, one at the top of the function (where
we allocate the memory) and the other at the bottom (where we
initialize it), but there's no clear reason to break it up like that.

Any reason not to instead do something like the attached?

-- 
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
В списке pgsql-hackers по дате отправления
От: Robert Haas
Дата:
От: Tom Lane
Дата:
Сообщение: Re: vacuum and row type
FAQ