On 15.12.2011 18:48, Tom Lane wrote:
Jeff Janes<jeff.ja...@gmail.com> writes:
On Thu, Dec 15, 2011 at 7:34 AM, Tom Lane<t...@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
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
