Re: DELETE vs TRUNCATE explanation
Matthew Woodcraft <matthew@woodcraft.me.uk>
From: Matthew Woodcraft <matthew@woodcraft.me.uk>
To: pgsql-performance@postgresql.org
Date: 2012-07-11T18:10:37Z
Lists: pgsql-hackers, pgsql-performance
Tom Lane wrote: > (3) The performance of the truncation itself should not be viewed in > isolation; subsequent behavior also needs to be considered. An example > of possible degradation is that index bloat would no longer be > guaranteed to be cleaned up over a series of repeated truncations. > (You might argue that if the table is small then the indexes couldn't > be very bloated, but I don't think that holds up over a long series.) > > IOW, I think it's fine as-is. I'd certainly wish to see many more > than one complainant before we expend effort in this area. I think a documentation change would be worthwhile. At the moment the TRUNCATE page says, with no caveats, that it is faster than unqualified DELETE. It surprised me to find that this wasn't true (with 7.2, again with small tables in a testsuite), and evidently it's still surprising people today. -M-
Commits
Same data as JSON:
GET /api/v1/messages/:b64id/commits
the thread's linked commits as JSON, with link sources.
API reference →
-
Scan the buffer pool just once, not once per fork, during relation drop.
- ece01aae4792 9.2.0 cited