3 ms·
"[TRUNCATE] does, in fact, release the disk space immediately — immediately upon COMMIT" Technically not, because postgres may still hold an open file handle u
by jeffdavis 13y ago
"[TRUNCATE] does, in fact, release the disk space immediately — immediately upon COMMIT"
Technically not, because postgres may still hold an open file handle until the next checkpoint. From a practical standpoint that's not an issue, except that it can cause confusion if you are monitoring disk space very closely.
But you are right that he is pretty far off: there is no need to vacuum and it's an O(1) operation.
- rosser 13y agoInteresting. I've never encountered that behavior, and it doesn't appear to be mentioned in a quick perusal of the manual page. The scenario you describe does make sense, and definitely could happen, though the impact would indeed be momentary and transient. Thanks for the clarification!
- garysieling 13y agoThanks, I've updated the post. I was unclear in what behavior we saw. The issue isn't that truncate isn't O(1), but that work that occurs after truncate has wildly inconsistent behavior in time (i.e. you see the same query on the same dataset take 10x the time). To me, that suggests that either Postgres is doing some work in the background, which hits at a random time, or that some query that is expecting statistics to have updated.