Thanks for your comments !

> On our project, when the power is out, we aren't receiving data anyways... just my two cents.

I am sorry, but I do not know how I can appropriately answer since I do not understand what you would like to ask me in this sentence. I understand that you have a project with UPS, and when the power failure occurs on UPS, suddenly your system cannot get data. Is my understanding right ? If so, then I agree with you and the reliability and durability of UPS is mandatory for your system.

> on a side note, would putting the wal on a tmpfs partition give you something similar?

There are two differences  between Sigres method and tmpfs with UPS method.
1:  XLogWrite
Even if you use tmpfs, your system executes XLogWrite which includes write(). Since write() is heavy system call, Sigres would be slightly faster than tmpfs method.
2: XLogWriteLock
Even if you use tmpfs, your system lock/release XLogWriteLock while Sigres ignores. Although the frequency of XLogWriteLock accesses is lower than XLogInsertLock, ignoring XLogWriteLock improves the performance especially in many core environment.

Best Regards,

-- Hideyuki

Gene wrote:
I think it would be great to have this kind of functionality built into postgres (optional and disabled by default of course) I use postgres mainly for its querying and concurrency features (a 10x increase in insert/update speed would be phenomenal) I know most people need 100% data integrity but as Hideyuki pointed out we all don't need 100%. On our project, when the power is out, we aren't receiving data anyways... just my two cents. on a side note, would putting the wal on a tmpfs partition give you something similar?

On 2/10/07, *Joshua D. Drake* <[EMAIL PROTECTED] <mailto:[EMAIL PROTECTED]>> wrote:

    Hideyuki Kawashima wrote:
    > Joshua,


    > The reason why I made the Sigres is, the advances of recent non
    > memories. Just now we do not usually use non volatile memories.
    But in
    > the near future, situation would change. I think if a non volatile
    > memories can be considered as a persistence device, PostgreSQL WAL
    > mechanism should be modified.
    > However, I do not use such devices usually. Thus I made Sigres which
    > requires UPS.

    This is actually very interesting. We (
    <>) have had
    several customers ask us how we can make PostgreSQL more reasonable
    within a flash environment.

    I agree with you that in the future you will see many such databases
    including PostgreSQL living on these devices.

    Tom? What do you think? Is there some room for movement here
    within the
    postgresql.conf to make something like sigres usable within PostgreSQL

    > Currently I have just ignored XLogWrite and WALWriteLock, but a
    > of mine (a Japanese great hacker of PostgreSQL) has more idea to
    > WAL if a battery supplied memory can be considered as a
    persistent device.

    We are coming up very quickly on a feature freeze for the next version
    of PostgreSQL. If... we can has something out quickly enough and in a
    thought out fashion, the hackers may be willing to accept a patch for
    8.3.. If not there is always 8.4..


    Joshua D. Drake


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

    Donate to the PostgreSQL Project:
    PostgreSQL Replication:

    ---------------------------(end of
    TIP 9: In versions below 8.0, the planner will ignore your desire to
           choose an index scan if your joining column's datatypes do not

Gene Hart
cell: 443-604-2679

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


Reply via email to