Re: [PERFORM] DELETE vs TRUNCATE explanation

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Robert Haas <robertmhaas(at)gmail(dot)com>
Cc: Jeff Janes <jeff(dot)janes(at)gmail(dot)com>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>, Daniel Farina <daniel(at)heroku(dot)com>, Craig Ringer <ringerc(at)ringerc(dot)id(dot)au>, Harold A(dot) Giménez <harold(dot)gimenez(at)gmail(dot)com>
Subject: Re: [PERFORM] DELETE vs TRUNCATE explanation
Date: 2012-07-16 19:18:53
Message-ID: 15955.1342466333@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers pgsql-performance

Robert Haas <robertmhaas(at)gmail(dot)com> writes:
> At any rate, I'm somewhat less convinced that the split was a good
> idea than I was when we did it, mostly because we haven't really gone
> anywhere with it subsequently.

BTW, while we are on the subject: hasn't this split completely broken
the statistics about backend-initiated writes? I don't see anything
in ForwardFsyncRequest that distinguishes whether it's being called in
the bgwriter or a regular backend.

regards, tom lane

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Robert Haas 2012-07-16 19:26:38 Re: [PERFORM] DELETE vs TRUNCATE explanation
Previous Message Robert Haas 2012-07-16 19:04:47 Re: CompactCheckpointerRequestQueue versus pad bytes

Browse pgsql-performance by date

  From Date Subject
Next Message Robert Haas 2012-07-16 19:26:38 Re: [PERFORM] DELETE vs TRUNCATE explanation
Previous Message Mark Thornton 2012-07-16 19:16:11 Re: very very slow inserts into very large table