Re: Moving more work outside WALInsertLock
От | Heikki Linnakangas |
---|---|
Тема | Re: Moving more work outside WALInsertLock |
Дата | |
Msg-id | 4EEA418C.9000304@enterprisedb.com обсуждение исходный текст |
Ответ на | Re: Moving more work outside WALInsertLock (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: Moving more work outside WALInsertLock
|
Список | pgsql-hackers |
On 15.12.2011 18:48, Tom Lane wrote: > Jeff Janes<jeff.janes@gmail.com> writes: >> On Thu, Dec 15, 2011 at 7:34 AM, Tom Lane<tgl@sss.pgh.pa.us> wrote: >>> This patch may or may not be useful, but this description of it is utter >>> nonsense, because we already do compute that before taking the lock. >>> Please try again to explain what you're doing? > >> Currently the CRC of all the data minus the header is computed outside the lock, >> but then the header's computation is added and the CRC is finalized >> inside the lock. > > Quite. AFAICS that is not optional, Right, my patch did not change that. > unless you are proposing to remove > the prev_link from the scope of the CRC, which is not exactly a > penalty-free change. We could CRC the rest of the record header before getting the lock, though, and only include the prev-link while holding the lock. I micro-benchmarked that a little bit, but didn't see much benefit from doing just that. Once you do more drastic changes so that the lock doesn't need to be held while copying the data and calculating the CRC of the record header, so that those things can be done in parallel, it matters even less. -- Heikki Linnakangas EnterpriseDB http://www.enterprisedb.com
В списке pgsql-hackers по дате отправления: