Re: patch review : Add ability to constrain backend temporary file space
От | Cédric Villemain |
---|---|
Тема | Re: patch review : Add ability to constrain backend temporary file space |
Дата | |
Msg-id | BANLkTinqUS0frHropGwiROBTcZ5h3Y2=pw@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: patch review : Add ability to constrain backend temporary file space (Mark Kirkwood <mark.kirkwood@catalyst.net.nz>) |
Ответы |
Re: patch review : Add ability to constrain backend temporary file
space
|
Список | pgsql-hackers |
2011/6/2 Mark Kirkwood <mark.kirkwood@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....
В списке pgsql-hackers по дате отправления: