Re: Getting rid of some more lseek() calls - Mailing list pgsql-hackers

From Thomas Munro
Subject Re: Getting rid of some more lseek() calls
Date
Msg-id CA+hUKGJGKb5GKdzvfgv4mNP5ECTY8CO5vBH3fPZGs6WmWEEOUQ@mail.gmail.com
Whole thread Raw
In response to Re: Getting rid of some more lseek() calls  (Michael Paquier <michael@paquier.xyz>)
Responses Re: Getting rid of some more lseek() calls
List 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 by date:

Previous
From: Thomas Munro
Date:
Subject: Re: WIP: WAL prefetch (another approach)
Next
From: Peter Eisentraut
Date:
Subject: Re: Unix-domain socket support on Windows