On Fri, Feb 14, 2020 at 4:47 AM Alvaro Herrera wrote:
> So, you said lseek() is faster than fstat, and we would only use the
> latter because we want to avoid the file position jumping ahead, even
> though it's slower. But if the next read/write is not going to care
> about the file position
On 2020-Feb-13, Thomas Munro wrote:
> On Thu, Feb 13, 2020 at 5:30 AM Alvaro Herrera
> wrote:
> > On 2020-Feb-12, Thomas Munro wrote:
> > > 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",
On Thu, Feb 13, 2020 at 02:51:44PM +1300, Thomas Munro wrote:
> Ok, how about this?
Alvaro's point sounds sensible to me. I like the approach you are
taking in 0001. At least it avoids more issues with WIN32 and stat()
(I hope to work on that at some point, we'll see..).
+/*
+ * pg_file_size
On Thu, Feb 13, 2020 at 5:30 AM Alvaro Herrera wrote:
> On 2020-Feb-12, Thomas Munro wrote:
> > 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
On 2020-Feb-12, Thomas Munro wrote:
> 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
On Wed, Feb 12, 2020 at 6:42 PM Michael Paquier 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,
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).
On Fri, Feb 7, 2020 at 1:37 PM Andres Freund wrote:
> Hm. This still leaves us with one source of SLRU_SEEK_FAILED. And that's
> really just for getting the file size. Should we rename that?
>
> Perhaps we should just replace lseek(SEEK_END) with fstat()? Or at least
> one wrapper function for
Hi,
On 2020-02-07 12:38:27 +1300, Thomas Munro wrote:
> Continuing the work done in commits 0dc8ead4 and c24dcd0c, here are a
> few more places where we could throw away some code by switching to
> pg_pread() and pg_pwrite().
Nice.
> From 5723976510f30385385628758d7118042c4e4bf6 Mon Sep 17
Hello,
Continuing the work done in commits 0dc8ead4 and c24dcd0c, here are a
few more places where we could throw away some code by switching to
pg_pread() and pg_pwrite().
0001-Use-pg_pread-and-pg_pwrite-in-slru.c.patch
Description: Binary data
0002-Use-pg_pwrite-in-rewriteheap.c.patch
10 matches
Mail list logo
