Re: Acclerating INSERT/UPDATE using UPS

From: Hideyuki Kawashima <kawasima(at)cs(dot)tsukuba(dot)ac(dot)jp>
To: "Joshua D(dot) Drake" <jd(at)commandprompt(dot)com>
Cc: pgsql-hackers(at)postgresql(dot)org
Subject: Re: Acclerating INSERT/UPDATE using UPS
Date: 2007-02-16 04:06:35
Message-ID: 45D52DCB.3000404@cs.tsukuba.ac.jp
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Joshua,

I revised. Now Sigres can be activated by setting "sigres = on" in
postgresql.conf.
You can download the version (0.1.2) from
http://sourceforge.jp/projects/sigres .

And, I attach the diff between PostgreSQL-8.2.1 and Sigres-0.1.2 to this
mail.

Thanks for your comments.

-- Hideyuki

Joshua D. Drake wrote:
> Hideyuki Kawashima wrote:
>
>> Joshua,
>>
>> 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.
>>
>
> The best way is to create a patch against -head and submit that patch
> with a complete description of why, and what. If you have test cases
> that show the improvement all the better.
>
> I would suggest though if you are going to submit the patch that you
> take a look at how you could disable/enable the feature within the
> postgresql.conf via a guc.
>
> Sincerely,
>
> Joshua D. Drake
>
>
>> However, Sigres modifies WAL which is the most important point of DBMS
>> on stability.
>> Although I myself could not find any bugs in Sigres, I am really afraid
>> of it. It a bug exists on Sigres, it puts everyone to huge
>> inconvenience... Therefore, before incorporating Sigres into PostgreSQL,
>> the code must be checked, and the behaviors of Sigres must be checked
>> carefully. Since PostgreSQL is a famous and wide spread software, I
>> strongly want to avoid losing its great reputation. Unfortunately in
>> Japan, I do not know any WAL hackers except for a friend of mine, and he
>> is too busy to check Sigres. So, if pgsql-hackers checks Sigres, I am
>> really happy.
>>
>> Best Regards,
>>
>> -- Hideyuki
>>
>> Joshua D. Drake wrote:
>>
>>> Hideyuki Kawashima wrote:
>>>
>>>
>>>> Joshua,
>>>>
>>>>
>>> :)
>>>
>>>
>>>
>>>> The reason why I made the Sigres is, the advances of recent non volatile
>>>> 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 (www.commandprompt.com) 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
>>> proper?
>>>
>>>
>>>
>>>> Currently I have just ignored XLogWrite and WALWriteLock, but a friend
>>>> of mine (a Japanese great hacker of PostgreSQL) has more idea to improve
>>>> 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..
>>>
>>> Sincerely,
>>>
>>> Joshua D. Drake
>>>
>>>
>>>
>>>
>>>
>>>
>
>
>

--
Hideyuki Kawashima (Ph.D), University of Tsukuba,
Graduate School of Systems and Information Engineering
Assistant Professor, TEL: +81-29-853-5322

Attachment Content-Type Size
pgsql821-sigres012.txt text/plain 24.3 KB

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Bruce Momjian 2007-02-16 04:55:53 Re: Avg performance for int8/numeric
Previous Message Tom Lane 2007-02-16 03:56:17 Re: Fixing insecure security definer functions