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
Дата: