On Fri, Mar 2, 2012 at 11:15 PM, Kevin Grittner
<Kevin.Grittner@wicourts.gov> wrote:
> Simon Riggs <simon@2ndQuadrant.com> wrote:
>
>> I like Marti's idea. At present, making his idea work could easily
>> mean checksums sink, so not sure whether to attempt to make that
>> work in detail.
>
> For my part, improving bulk load performance and TRUNCATE
> transactional semantics would trump checksums. If we have to defer
> one or the other to a later release, I would prefer that we bump
> checksums.
>
> While I understand the desire for checksums, and understand others
> have had situations where they would have helped, so far I have yet
> to run into a situation where I feel they would have helped me. The
> hint bit and freeze issues require ongoing attention and have real
> performance consequences on a regular basis. And closing the window
> for odd transactional semantics on TRUNCATE versus DELETE of all
> rows in a table would be one less thing to worry about, in my world.
Since you supported this, I've invested the time to make it work. It
doesn't look like it needs to be either-or.
Please review the safe_truncate.v2.patch and
copy_autofrozen.v359.patch, copied here to assist testing and
inspection.
At present those patches handle only the TRUNCATE/COPY optimisation
but we could easily add CTAS, CREATE/COPY, CLUSTERVACUUM FULL etc..
--
Simon Riggs http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services
