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  (Mark Kirkwood <mark.kirkwood@catalyst.net.nz>)
Список 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 по дате отправления:

Предыдущее
От: Noah Misch
Дата:
Сообщение: Re: Domains versus polymorphic functions, redux
Следующее
От: Robert Haas
Дата:
Сообщение: Re: storing TZ along timestamps