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
|
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: