Tom, * Tom Lane (t...@sss.pgh.pa.us) wrote: > FWIW, I'm not certain that Stephen is correct to claim that we have > some concrete problem with sparse files. We certainly don't *depend* > on sparse storage anyplace else, nor write data in a way that would be > likely to trigger it; but I'm not aware that we need to work hard to > avoid it.
I don't have any concrete evidence that there is an issue, just a recollection of bringing up exactly the idea of turning entirely empty 1G segments into sparse files to free that space back to the filesystem during a VACUUM during a discussion somewhere along the way and being told that it'd be bad because we would run into issues later when we try to write those pages back out and discover we're out of disk space. Naturally, there's a lot to consider with such a change to VACUUM like how we would WAL that and how we'd make sure that nothing is about to try and use any of those pages (perhaps start at the end of the segment and lock the pages, or just try to get an exclusive lock on the table as we do when we try to truncate the relation because there's free space at the end?), but it'd be a very interesting project to consider, if we are willing to accept sparse heap files. Another interesting idea might be to somehow change the now-empty relation into just a place-holder that says "assume I'm 1G in size and empty." but actually have the file be shrunk. Anyway, I tend to agree with the sentiment that we don't need this patch to change the behavior here and perhaps it'll be good to see what happens when people start using these sparsh hash indexes, maybe that will shed some light on if we have anything to worry about here or not, and if not then we can consider having sparse files elsewhere. Thanks! Stephen
signature.asc
Description: Digital signature