Re: Acclerating INSERT/UPDATE using UPS - Mailing list pgsql-hackers

From Bruce Momjian
Subject Re: Acclerating INSERT/UPDATE using UPS
Date
Msg-id 200702261444.l1QEi1h03479@momjian.us
Whole thread Raw
In response to Re: Acclerating INSERT/UPDATE using UPS  ("Joshua D. Drake" <jd@commandprompt.com>)
Responses Re: Acclerating INSERT/UPDATE using UPS  ("Simon Riggs" <simon@2ndquadrant.com>)
List pgsql-hackers
Joshua D. Drake wrote:
> Christopher Browne wrote:
> > A long time ago, in a galaxy far, far away, kawasima@cs.tsukuba.ac.jp (Hideyuki Kawashima) wrote:
> >> I appreciate your great suggestion!
> >> It is great honor for me if Sigres will be merged to PostgreSQL.
> >> Since the changes of Sigres from PostgreSQL-8.2.1 are not many,
> >> and moreover, all of changes are surrounded with #ifdef SIGRES --- #endif,
> >> incorporating Sigres into PostgreSQL would be easy.
> > 
> > You should consider submitting a patch for this against CVS HEAD.
> > 
> > And actually, I'd think it a better idea to define a GUC variable and
> > use that to control whether Sigres is active or not.
> > 
> > At the more sophisticated end of the spectrum, you might set things up
> > so that it could be activated/deactivated at runtime by a superuser.
> > 
> > At the less sophisticated end, it might need to be configured in
> > postgresql.conf...
> 
> Whatever happen with this?

I would like to see more analysis about why Sigres is faster than an
in-memory file system.  I think the idea was that locking was reduced
but I am unclear on why locking is different in the two cases.

--  Bruce Momjian  <bruce@momjian.us>          http://momjian.us EnterpriseDB
http://www.enterprisedb.com
 + If your life is a hard drive, Christ can be your backup. +


pgsql-hackers by date:

Previous
From: Devrim GUNDUZ
Date:
Subject: Re: [GENERAL] urgent: upgraded to 8.2, getting kernel panics
Next
From: mark@mark.mielke.cc
Date:
Subject: Re: SCMS question