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
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) |