Horton

Thread

  1. Anything to be gained from a 'Postgres Filesystem'?

    Matt Clark <matt@ymogen.net> — 2004-10-21T07:58:01Z

    I suppose I'm just idly wondering really.  Clearly it's against PG
philosophy to build an FS or direct IO management into PG, but now it's so
relatively easy to plug filesystems into the main open-source Oses, It
struck me that there might be some useful changes to, say, XFS or ext3, that
could be made that would help PG out.

I'm thinking along the lines of an FS that's aware of PG's strategies and
requirements and therefore optimised to make those activities as efiicient
as possible - possibly even being aware of PG's disk layout and treating
files differently on that basis.

Not being an FS guru I'm not really clear on whether this would help much
(enough to be worth it anyway) or not - any thoughts?  And if there were
useful gains to be had, would it need a whole new FS or could an existing
one be modified?

So there might be (as I said, I'm not an FS guru...):
* great append performance for the WAL?
* optimised scattered writes for checkpointing?
* Knowledge that FSYNC is being used for preserving ordering a lot of the
time, rather than requiring actual writes to disk (so long as the writes
eventually happen in order...)?


Matt



Matt Clark
Ymogen Ltd
P: 0845 130 4531
W: https://ymogen.net/
M: 0774 870 1584

  2. Re: Anything to be gained from a 'Postgres Filesystem'?

    PFC <lists@boutiquenumerique.com> — 2004-10-21T08:33:31Z

    	Reiser4 ?

On Thu, 21 Oct 2004 08:58:01 +0100, Matt Clark <matt@ymogen.net> wrote:

> I suppose I'm just idly wondering really.  Clearly it's against PG
> philosophy to build an FS or direct IO management into PG, but now it's  
> so
> relatively easy to plug filesystems into the main open-source Oses, It
> struck me that there might be some useful changes to, say, XFS or ext3,  
> that
> could be made that would help PG out.
>
> I'm thinking along the lines of an FS that's aware of PG's strategies and
> requirements and therefore optimised to make those activities as  
> efiicient
> as possible - possibly even being aware of PG's disk layout and treating
> files differently on that basis.
>
> Not being an FS guru I'm not really clear on whether this would help much
> (enough to be worth it anyway) or not - any thoughts?  And if there were
> useful gains to be had, would it need a whole new FS or could an existing
> one be modified?
>
> So there might be (as I said, I'm not an FS guru...):
> * great append performance for the WAL?
> * optimised scattered writes for checkpointing?
> * Knowledge that FSYNC is being used for preserving ordering a lot of the
> time, rather than requiring actual writes to disk (so long as the writes
> eventually happen in order...)?
>
>
> Matt
>
>
>
> Matt Clark
> Ymogen Ltd
> P: 0845 130 4531
> W: https://ymogen.net/
> M: 0774 870 1584
>
>
> ---------------------------(end of broadcast)---------------------------
> TIP 2: you can get off all lists at once with the unregister command
>     (send "unregister YourEmailAddressHere" to majordomo@postgresql.org)
>

  3. Re: Anything to be gained from a 'Postgres Filesystem'?

    Steinar H. Gunderson <sgunderson@bigfoot.com> — 2004-10-21T10:27:27Z

    On Thu, Oct 21, 2004 at 08:58:01AM +0100, Matt Clark wrote:
> I suppose I'm just idly wondering really.  Clearly it's against PG
> philosophy to build an FS or direct IO management into PG, but now it's so
> relatively easy to plug filesystems into the main open-source Oses, It
> struck me that there might be some useful changes to, say, XFS or ext3, that
> could be made that would help PG out.

This really sounds like a poor replacement for just making PostgreSQL use raw
devices to me. (I have no idea why that isn't done already, but presumably it
isn't all that easy to get right. :-) )

/* Steinar */
-- 
Homepage: http://www.sesse.net/

  4. Re: Anything to be gained from a 'Postgres Filesystem'?

    Neil Conway <neilc@samurai.com> — 2004-10-21T12:02:00Z

    Matt Clark wrote:
> I'm thinking along the lines of an FS that's aware of PG's strategies and
> requirements and therefore optimised to make those activities as efiicient
> as possible - possibly even being aware of PG's disk layout and treating
> files differently on that basis.

As someone else noted, this doesn't belong in the filesystem (rather the 
kernel's block I/O layer/buffer cache). But I agree, an API by which we 
can tell the kernel what kind of I/O behavior to expect would be good. 
The kernel needs to provide good behavior for a wide range of 
applications, but the DBMS can take advantage of a lot of 
domain-specific information. In theory, being able to pass that 
domain-specific information on to the kernel would mean we could get 
better performance without needing to reimplement large chunks of 
functionality that really ought to be done by the kernel anyway (as 
implementing raw I/O would require, for example). On the other hand, it 
would probably mean adding a fair bit of OS-specific hackery, which 
we've largely managed to avoid in the past.

The closest API to what you're describing that I'm aware of is 
posix_fadvise(). While that is technically-speaking a POSIX standard, it 
is not widely implemented (I know Linux 2.6 implements it; based on some 
quick googling, it looks like AIX does too). Using posix_fadvise() has 
been discussed in the past, so you might want to search the archives. We 
could use FADV_SEQUENTIAL to request more aggressive readahead on a file 
that we know we're about to sequentially scan. We might be able to use 
FADV_NOREUSE on the WAL. We might be able to get away with specifying 
FADV_RANDOM for indexes all of the time, or at least most of the time. 
One question is how this would interact with concurrent access (AFAICS 
there is no way to fetch the "current advice" on an fd...)

Also, I would imagine Win32 provides some means to inform the kernel 
about your expected I/O pattern, but I haven't checked. Does anyone know 
of any other relevant APIs?

-Neil

  5. Re: Anything to be gained from a 'Postgres Filesystem'?

    Jan Dittmer <jdittmer@ppp0.net> — 2004-10-21T15:02:00Z

    Neil Conway wrote:
> Also, I would imagine Win32 provides some means to inform the kernel 
> about your expected I/O pattern, but I haven't checked. Does anyone know 
> of any other relevant APIs?

See CreateFile, Parameter dwFlagsAndAttributes

http://msdn.microsoft.com/library/default.asp?url=/library/en-us/fileio/base/createfile.asp

There is FILE_FLAG_NO_BUFFERING, FILE_FLAG_OPEN_NO_RECALL,
FILE_FLAG_RANDOM_ACCESS and even FILE_FLAG_POSIX_SEMANTICS

Jan

  6. Re: Anything to be gained from a 'Postgres Filesystem'?

    Sean Chittenden <sean@chittenden.org> — 2004-10-21T18:40:08Z

    > As someone else noted, this doesn't belong in the filesystem (rather 
> the kernel's block I/O layer/buffer cache). But I agree, an API by 
> which we can tell the kernel what kind of I/O behavior to expect would 
> be good.
[snip]
> The closest API to what you're describing that I'm aware of is 
> posix_fadvise(). While that is technically-speaking a POSIX standard, 
> it is not widely implemented (I know Linux 2.6 implements it; based on 
> some quick googling, it looks like AIX does too).

Don't forget about the existence/usefulness/widely implemented 
madvise(2)/posix_madvise(2) call, which can give the OS the following 
hints: MADV_NORMAL, MADV_SEQUENTIAL, MADV_RANDOM, MADV_WILLNEED, 
MADV_DONTNEED, and MADV_FREE.  :)  -sc

-- 
Sean Chittenden

  7. Re: Anything to be gained from a 'Postgres Filesystem'?

    Decibel! <decibel@decibel.org> — 2004-10-21T22:18:30Z

    Note that most people are now moving away from raw devices for databases
in most applicaitons. The relatively small performance gain isn't worth
the hassles.

On Thu, Oct 21, 2004 at 12:27:27PM +0200, Steinar H. Gunderson wrote:
> On Thu, Oct 21, 2004 at 08:58:01AM +0100, Matt Clark wrote:
> > I suppose I'm just idly wondering really.  Clearly it's against PG
> > philosophy to build an FS or direct IO management into PG, but now it's so
> > relatively easy to plug filesystems into the main open-source Oses, It
> > struck me that there might be some useful changes to, say, XFS or ext3, that
> > could be made that would help PG out.
> 
> This really sounds like a poor replacement for just making PostgreSQL use raw
> devices to me. (I have no idea why that isn't done already, but presumably it
> isn't all that easy to get right. :-) )
> 
> /* Steinar */
> -- 
> Homepage: http://www.sesse.net/
> 
> ---------------------------(end of broadcast)---------------------------
> TIP 1: subscribe and unsubscribe commands go to majordomo@postgresql.org
> 

-- 
Jim C. Nasby, Database Consultant               decibel@decibel.org 
Give your computer some brain candy! www.distributed.net Team #1828

Windows: "Where do you want to go today?"
Linux: "Where do you want to go tomorrow?"
FreeBSD: "Are you guys coming, or what?"