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

From Joshua D. Drake
Subject Re: Acclerating INSERT/UPDATE using UPS
Date
Msg-id 45CE93B6.6040101@commandprompt.com
Whole thread Raw
In response to Re: Acclerating INSERT/UPDATE using UPS  (Hideyuki Kawashima <kawasima@cs.tsukuba.ac.jp>)
Responses Re: Acclerating INSERT/UPDATE using UPS  (Hideyuki Kawashima <kawasima@cs.tsukuba.ac.jp>)
List pgsql-hackers
> BTW, Joshua, could you please let me know or give me any pointers for
> the reason why fsync=off option exists on PostgreSQL although PostgreSQL

A couple of reasons that I can think of. One would be data loads or
restoring from backup. Another would be on data that you can afford to
throw away.


> developers does not allow sacrificing data integrity ?
> If the reason is famous and clear in the community, I am sorry for
> bothering you.

No bother at all! We invite all good ideas and I am glad to see more
from our eastern community participate.

Another option you might want to look at to further give yourself a
boost in performance is full_page_writes.

Joshua D. Drake



> 
> 
> -- Hideyuki
> 
> Joshua D. Drake wrote:
>> Hideyuki Kawashima wrote:
>>   
>>> Hello PostgreSQL Hackers,
>>>
>>> I have made a modification of PostgreSQL which accelerates INSERT/UPDATE using UPS. The name of the software is
"Sigres",and the philosophy is considering a battery supplied memory as a persistent device instead of a disk. You can
downloadSigres from http://sourceforge.jp/projects/sigres/ .
 
>>>
>>> In the maximum case, Sigres is 7 times faster than PostgreSQL default (fsync=on) in my environment (CoreDuo
2.66GHz,UDMA/133), and it is also 10% faster than PostgreSQL without fsync (fsync=off).
 
>>>     
>> Interesting and what happens when the UPS fails? My main concern is that
>> one of the purposes of PostgreSQL is data integrity. I am all for every
>> performance enhancement we can achieve, that does *not* sacrifice that.
>>
>> Sincerely,
>>
>> Joshua D. Drake
>>
>>   
>>> The magic lies in usually skipping XLogWrite() and ignoring WALWriteLock. The exceptions are XLogWrite() calls from
AdvanceXLInsertBuffer().In addition, in XLogFileClose() issue_xlog_fsync() before close(). (In this point, Sigres is
differentfrom just simply setting fsync=off.)
 
>>>
>>> Although I think Sigres can be considered as one of the future directions of PostgreSQL, I do not know whether this
softwarecan be accepted or not. Could you please give me some comments ?
 
>>>
>>> Best Regards,
>>>
>>> -- Hideyuki Kawashima 
>>> Assistant Professor, University of Tsukuba
>>>
>>>
>>>
>>> ---------------------------(end of broadcast)---------------------------
>>> TIP 1: if posting/reading through Usenet, please send an appropriate
>>>        subscribe-nomail command to majordomo@postgresql.org so that your
>>>        message can get through to the mailing list cleanly
>>>
>>>     
>>
>>   
> 
> 
> ---------------------------(end of broadcast)---------------------------
> TIP 6: explain analyze is your friend
> 


-- 
     === The PostgreSQL Company: Command Prompt, Inc. ===
Sales/Support: +1.503.667.4564 || 24x7/Emergency: +1.800.492.2240
Providing the most comprehensive  PostgreSQL solutions since 1997            http://www.commandprompt.com/

Donate to the PostgreSQL Project: http://www.postgresql.org/about/donate
PostgreSQL Replication: http://www.commandprompt.com/products/



pgsql-hackers by date:

Previous
From: Hideyuki Kawashima
Date:
Subject: Re: Acclerating INSERT/UPDATE using UPS
Next
From: Hideyuki Kawashima
Date:
Subject: Re: Acclerating INSERT/UPDATE using UPS