Re: Getting rid of some more lseek() calls

Поиск
Список
Период
Сортировка
От Thomas Munro
Тема Re: Getting rid of some more lseek() calls
Дата
Msg-id CA+hUKGJGKb5GKdzvfgv4mNP5ECTY8CO5vBH3fPZGs6WmWEEOUQ@mail.gmail.com
обсуждение исходный текст
Ответ на Re: Getting rid of some more lseek() calls  (Michael Paquier <michael@paquier.xyz>)
Ответы Re: Getting rid of some more lseek() calls  (Alvaro Herrera <alvherre@2ndquadrant.com>)
Список pgsql-hackers
On Wed, Feb 12, 2020 at 6:42 PM Michael Paquier <michael@paquier.xyz> wrote:
> On Tue, Feb 11, 2020 at 06:04:09PM +1300, Thomas Munro wrote:
> > lseek(SEEK_END) seems to be nearly twice as fast as fstat() if you
> > just call it in a big loop, on Linux and FreeBSD (though I didn't
> > investigate exactly why, mitigations etc, it certainly returns more
> > stuff so there's that).
>
> Interesting.  What of Windows?  We've had for some time now problem
> with fetching the size of files larger than 4GB (COPY, dumps..).  I am
> wondering if we could not take advantage of that for those cases:
> https://www.postgresql.org/message-id/15858-9572469fd3b73263@postgresql.org

Hmm.  Well, on Unix we have to choose between "tell me the size but
also change the position that I either don't care about or have to
undo", and "tell me the size but also tell me all this other stuff I
don't care about".  Since Windows apparently has GetFileSizeEx(), why
not use that when that's exactly what you want?  It apparently
understands large files.

https://docs.microsoft.com/en-us/windows/win32/api/fileapi/nf-fileapi-getfilesizeex



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

Предыдущее
От: Thomas Munro
Дата:
Сообщение: Re: WIP: WAL prefetch (another approach)
Следующее
От: Peter Eisentraut
Дата:
Сообщение: Re: Unix-domain socket support on Windows