On Wed, 2006-09-06 at 18:55 -0400, Chris Browne wrote:
> [EMAIL PROTECTED] (Jeff Davis) writes:
> >> > Do you see an advantage in using LFS for PostgreSQL?
> >> 
> >> Hey guys - I think the original poster only meant to suggest that it
> >> was *interesting*... :-)
> >> 
> >
> > I see, my mistake.
> >From a reliability perspective, I can see some value to it...  
> I have seen far too many databases corrupted by journalling gone bad
> in the past year...  :-(

Can you elaborate a little? Which filesystems have been problematic?
Which filesystems are you more confident in?

> >
> > And if there is an improvement, shouldn't that be a project for
> > something like Linux, where other databases could also benefit? It
> > could just be implemented as a database-specific filesystem.
> The classic problem with log structured filesystems is that sequential
> reads tend to be less efficient than in overwriting systems; perhaps
> if they can get "vacuuming" to be done frequently enough, that might
> change the shape of things.
> That would be a relevant lesson that _we_ have discovered that is
> potentially applicable to filesystem implementors.
> And I don't consider this purely of academic interest; the ability to:
>  a) Avoid the double writing of journalling, and
>  b) Avoid the risks of failures due to misordered writes
> are both genuinely valuable.

Right, LFS is promising in a number of ways. I've read about it in the
past, and it would be nice if this NILFS implementation sparks some new
research in the area.

        Jeff Davis

---------------------------(end of broadcast)---------------------------
TIP 9: In versions below 8.0, the planner will ignore your desire to
       choose an index scan if your joining column's datatypes do not

Reply via email to