Stephen Frost <sfr...@snowman.net> writes: > * Tom Lane (t...@sss.pgh.pa.us) wrote: >> It's true that as soon as we need another overflow page, that's going to >> get dropped beyond the 2^{N+1}-1 point, and the *apparent* size of the >> index will grow quite a lot. But any modern filesystem should handle >> that without much difficulty by treating the index as a sparse file.
> Uh, last I heard we didn't allow or want sparse files in the backend > because then we have to handle a possible out-of-disk-space failure on > every write. For a hash index, this would happen during a bucket split, which would need to be resilient against out-of-disk-space anyway. >> There may be some work to be done in places like pg_basebackup to >> recognize and deal with sparse files, but it doesn't seem like a >> reason to panic. > Well, and every file-based backup tool out there.. Weren't you the one leading the charge to deprecate use of file-based backup? regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers