[PERFORM] Reiser4

2004-08-13 Thread Pierre-Frdric Caillaud

ReiserFS 4 is (will be) a filesystem that implements transactions.
	Are there any plans in a future Postgresql version to support a special  
fsync method for Reiser4 which will use the filesystem's transaction  
engine, instead of an old kludge like fsync(), with a possibility of  
vastly enhanced performance ?

	Is there also a possibility to tell Postgres : I don't care if I lose 30  
seconds of transactions on this table if the power goes out, I just want  
to be sure it's still ACID et al. compliant but you can fsync less often  
and thus be faster (with a possibility of setting that on a per-table  
basis) ?

Thanks.
---(end of broadcast)---
TIP 2: you can get off all lists at once with the unregister command
   (send unregister YourEmailAddressHere to [EMAIL PROTECTED])


Re: [PERFORM] Reiser4

2004-08-13 Thread Josh Berkus
Pierre,

   Are there any plans in a future Postgresql version to support a special  
 fsync method for Reiser4 which will use the filesystem's transaction  
 engine, instead of an old kludge like fsync(), with a possibility of  
 vastly enhanced performance ?

I don't know of any such in progress right now.  Why don't you start it?  It 
would have to be an add-in since we support 28 operating systems and Reiser 
is AFAIK Linux-only, but it sounds like an interesting experiment.

   Is there also a possibility to tell Postgres : I don't care if I lose 30  
 seconds of transactions on this table if the power goes out, I just want  
 to be sure it's still ACID et al. compliant but you can fsync less often  
 and thus be faster (with a possibility of setting that on a per-table  
 basis) ?

Not per-table, no, but otherwise take a look at the Background Writer feature 
of 8.0.

-- 
-Josh Berkus
 A developer of Very Little Brain
 Aglio Database Solutions
 San Francisco


---(end of broadcast)---
TIP 7: don't forget to increase your free space map settings


Re: [PERFORM] Reiser4

2004-08-13 Thread Bruce Momjian
Pierre-Frédéric Caillaud wrote:
   Is there also a possibility to tell Postgres : I don't care if I lose 30  
 seconds of transactions on this table if the power goes out, I just want  
 to be sure it's still ACID et al. compliant but you can fsync less often  
 and thus be faster (with a possibility of setting that on a per-table  
 basis) ?

I have been thinking about this.  Informix calls it buffered logging and
it would be a good feature.

Added to TODO:

* Allow buffered WAL writes and fsync

  Instead of guaranteeing recovery of all committed transactions, this
  would provide improved performance by delaying WAL writes and fsync
  so an abrupt operating system restart might lose a few seconds of
  committed transactions but still be consistent.  We could perhaps
  remove the 'fsync' parameter (which results in an an inconsistent
  database) in favor of this capability.

-- 
  Bruce Momjian|  http://candle.pha.pa.us
  [EMAIL PROTECTED]   |  (610) 359-1001
  +  If your life is a hard drive, |  13 Roberts Road
  +  Christ can be your backup.|  Newtown Square, Pennsylvania 19073

---(end of broadcast)---
TIP 5: Have you checked our extensive FAQ?

   http://www.postgresql.org/docs/faqs/FAQ.html


Re: [PERFORM] Reiser4

2004-08-13 Thread Bruce Momjian
Josh Berkus wrote:
 Pierre,
 
  Are there any plans in a future Postgresql version to support a special  
  fsync method for Reiser4 which will use the filesystem's transaction  
  engine, instead of an old kludge like fsync(), with a possibility of  
  vastly enhanced performance ?
 
 I don't know of any such in progress right now.  Why don't you start it?  It 
 would have to be an add-in since we support 28 operating systems and Reiser 
 is AFAIK Linux-only, but it sounds like an interesting experiment.
 
  Is there also a possibility to tell Postgres : I don't care if I lose 30  
  seconds of transactions on this table if the power goes out, I just want  
  to be sure it's still ACID et al. compliant but you can fsync less often  
  and thus be faster (with a possibility of setting that on a per-table  
  basis) ?
 
 Not per-table, no, but otherwise take a look at the Background Writer feature 
 of 8.0.

Actually the fsync of WAL is the big performance issue here.  I added a
TODO item about it.

-- 
  Bruce Momjian|  http://candle.pha.pa.us
  [EMAIL PROTECTED]   |  (610) 359-1001
  +  If your life is a hard drive, |  13 Roberts Road
  +  Christ can be your backup.|  Newtown Square, Pennsylvania 19073

---(end of broadcast)---
TIP 7: don't forget to increase your free space map settings