Re: Caching number of blocks in relation to avoi lseek.

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: Caching number of blocks in relation to avoi lseek.
Дата
Msg-id 6002.960863681@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Re: Caching number of blocks in relation to avoi lseek.  (Denis Perchine <dyp@perchine.com>)
Ответы Re: Caching number of blocks in relation to avoi lseek.  (Alfred Perlstein <bright@wintelcom.net>)
Список pgsql-hackers
Denis Perchine <dyp@perchine.com> writes:
> No... You did not get me. I am talking about completly different thing:
> I strace'ed postgres binary when doing queries and found out that it
> do lseek after each read, and the difference in the position is 8096.
> It means that we are in correct position anyway and do not need additional lseek.

Oh.  Hmm.  Not sure if it's really worth the trouble, but you could try
having fd.c keep track of the current seek position of VFDs when they
are open as well as when they are closed, and optimize away the lseek
call in FileSeek if the position is already right.  You'd have to think
carefully about what to do if a read or write fails, however --- where
has the kernel left its seek position in that case?  Possibly this could
be dealt with by setting the internal position to "unknown" anytime
we're not perfectly sure where the kernel is.
        regards, tom lane


В списке pgsql-hackers по дате отправления:

Предыдущее
От: Tom Lane
Дата:
Сообщение: Re: Proposal for fixing intra-query memory leaks
Следующее
От: Tom Lane
Дата:
Сообщение: Re: memory management suggestion