Tom, Gavin,

> > To get decent I/O you need 1MB fundamental units all the way down the
> > stack.
> It would also be a good idea to have an application that isn't likely
> to change a single bit in a 1MB range and then expect you to record
> that change.  This pretty much lets Postgres out of the picture.

We're looking at this pretty much just for data warehousing, where you 
constantly have gigabytes of data which don't change from month to month or 
even year to year.   I agree that it would *not* be an optimization for OLTP 
systems.  Which is why a build-time option would be fine.

> Ummm... I don't see anything here which will be a win for Postgres. The
> transactional semantics we're interested in are fairly complex:
> 1) Modifications to multiple objects can become visible to the system
> atomically
> 2) On error, a series of modifications which had been grouped together
> within a transaction can be rolled back
> 3) Using object version information, determine which version of which
> object is visible to a given session
> 4) Using version information and locking, detect and resolve read/write
> and write/write conflicts

I wasn't thinking of database transactions.  I was thinking specifically of 
using Reiser4 transactions (and other transactional filesytems) to do things 
like eliminate the need for full page writes in the WAL.  Filesystems are 
low-level things which should take care of low-level needs, like making sure 
an 8K page got written to disk even in the event of a system failure.

Josh Berkus
Aglio Database Solutions
San Francisco

---------------------------(end of broadcast)---------------------------
TIP 2: Don't 'kill -9' the postmaster

Reply via email to