On 03/06/11 12:33, Cédric Villemain wrote:
2011/6/2 Mark Kirkwood<mark.kirkw...@catalyst.net.nz>:
On 01/06/11 09:24, Cédric Villemain wrote:
* I am not sure it is better to add a fileSize like you did or use
relationgetnumberofblock() when file is about to be truncated or
unlinked, this way the seekPos should be enough to increase the global
counter.
The temp files are not relations so I'd have to call stat I guess. Now
truncate/unlink can happen quite a lot (e.g hash with many files) and I
wanted to avoid adding too many library calls to this code for performance
reasons, so on balance I'm thinking it is gonna be more efficient to
remember the size in the Vfd.
I am not sure temporary relation are truncated. I have not checked
right now, but IIRC, we don't need to truncate it. And I believe it
would defeat the log_temp feature because log_temp is done on
FileClose() only.
If we are to add a field in struct vfd to keep the filesize then some
optimization may happens for logging too....
We pretty much need to store the file size I think, due to needing to
work out if FileWrite is re-writing inside the file or extending it. So
maybe we could avoid a stat on unlink too (mind you it is a nice
validity check that the ongoing size accounting is correct). I was/am
keen to avoid changing too much here (heh - maybe I'm being too timid...).
Cheers
Mark
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
