Re: Getting rid of some more lseek() calls

From: Thomas Munro <thomas(dot)munro(at)gmail(dot)com>
To: Michael Paquier <michael(at)paquier(dot)xyz>
Cc: Andres Freund <andres(at)anarazel(dot)de>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Getting rid of some more lseek() calls
Date: 2020-02-12 07:08:06
Message-ID: CA+hUKGJGKb5GKdzvfgv4mNP5ECTY8CO5vBH3fPZGs6WmWEEOUQ@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Wed, Feb 12, 2020 at 6:42 PM Michael Paquier <michael(at)paquier(dot)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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Amit Kapila 2020-02-12 08:12:23 Re: ERROR: subtransaction logged without previous top-level txn record
Previous Message Thomas Munro 2020-02-12 06:52:42 Re: WIP: WAL prefetch (another approach)