I will write a technical document about Sigres in a week.
Hideyuki
Bruce Momjian wrote:
I am still unclear why sigres is better than a temporary file system. I
relize your patch is faster, but what is about your patch that makes it
faster.
And if we were going to add such capability, we
I am still unclear why sigres is better than a temporary file system. I
relize your patch is faster, but what is about your patch that makes it
faster.
And if we were going to add such capability, we would name it based on
what it does, rather than on a 'sigres' mode.
Simon,
Not checkpointing at all is not a good plan, since this will lead to an
enormous build up of WAL files and a very long recovery time if the
system does fail.
I appreciate your detailed comments.
Following your comments, I revised the problem.
Sigres-0.1.3 does checkpointings.
In
Joshua D. Drake wrote:
From an deployable application perspective, this could be a big deal. We
are already starting to see very large traction in the Win32 desktop app
arena.
There seem to be a few overlapping proposals in terms of reducing
various guarantees in the name of performance.
As
Joshua D. Drake wrote:
Christopher Browne wrote:
A long time ago, in a galaxy far, far away, [EMAIL PROTECTED] (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
On Mon, 2007-02-26 at 09:44 -0500, Bruce Momjian wrote:
Joshua D. Drake wrote:
Christopher Browne wrote:
A long time ago, in a galaxy far, far away, [EMAIL PROTECTED] (Hideyuki
Kawashima) wrote:
I appreciate your great suggestion!
It is great honor for me if Sigres will be merged
Simon Riggs [EMAIL PROTECTED] writes:
Reading through the design, I see the following
- bgwriter performs XLogWrite, not each backend
- WAL fsync is only performed when WAL file fills
- no checkpoints are performed until shutdown
Not checkpointing at all is not a good plan, since this will
Christopher Browne wrote:
A long time ago, in a galaxy far, far away, [EMAIL PROTECTED] (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
Bruce,
Let me answer to your question.
Question 1: How much faster is it ?
To answer to your question, I measured execution times of INSERT
operations on concurrent accesses on dual-core x 2 CPU (each 2.80GHz),
In the experiment, each client issues 5000 INSERT operations concurrently.
The
Tom,
In my experience, in last April, a BBWC solution did not accelerate
PostgreSQL well.
The device which I tried was i-ram by gigabyte
(http://techreport.com/reviews/2006q1/gigabyte-iram/index.x?pg=1 ).
The i-ram showed only a little performance improvement compared to
PostgreSQL with fsync to
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
Christopher Browne wrote:
[EMAIL PROTECTED] (Hideyuki Kawashima) wrote:
Joshua,
I appreciate your quick informative reply. And, I also really
appreciate your kind comments. Since I have joined this ML 3 hours
ago, I tried to be polite and slightly nervous. But I was relieved
by your
Tom Lane wrote:
Gene [EMAIL PROTECTED] writes:
... just my two cents. on a side note, would putting the wal on a
tmpfs partition give you something similar?
Indeed, I'm wondering why one needs to hack the Postgres core to throw
away data integrity guarantees; there are plenty of ways to
I was curious to see how postgres would perform with wal on a tmpfs vs disk
here are some numbers I got from pgbench. Let me know if I did something
stupid, this is the first time I've used pgbench. The wal on tmpfs method is
not significantly faster.
[[ WAL ON TMPFS ]]
pgbench -i -s 10 -U
On 2/12/07, Gene [EMAIL PROTECTED] wrote:
I was curious to see how postgres would perform with wal on a tmpfs vs
disk here are some numbers I got from pgbench. Let me know if I did
something stupid, this is the first time I've used pgbench. The wal on tmpfs
method is not significantly faster.
Gene [EMAIL PROTECTED] writes:
I was curious to see how postgres would perform with wal on a tmpfs vs disk
here are some numbers I got from pgbench. Let me know if I did something
stupid, this is the first time I've used pgbench. The wal on tmpfs method is
not significantly faster.
This
Bruce,
Thanks for your comments, and let me answer to your question.
Sigres is *not* significantly faster than just creating a file system on
the permanent memory and putting xlog on there.
Sigres is slightly faster than the case because each backend does not
call XLogWrite while bgWriter
Hideyuki Kawashima wrote:
Bruce,
Thanks for your comments, and let me answer to your question.
Sigres is *not* significantly faster than just creating a file system on
the permanent memory and putting xlog on there.
Sigres is slightly faster than the case because each backend does not
Gene,
I think tmpfs/ramfs method would increase the performance of PostgreSQL
when workload is write-intensive.
Does pgbench issue write intensive queries ? Since I do not know the
detailed queries issued in pgbench, I am happy if you teach me.
Regards,
-- Hideyuki
Gene wrote:
I was
Christopher,
Thanks for your comments and I am sorry for my bad response because of
my business. In the first place, criticisms are welcome since without
criticisms and discussions, I cannot improve my idea.
Christopher, thanks to your comments, I understood why this community
does not incline
Christopher,
Thanks for your advices !
OK, I will submit a patch as soon as possible.
In the patch, Sigres will be activated by postgresql.conf.
Best Regards,
-- Hideyuki
A long time ago, in a galaxy far, far away, [EMAIL PROTECTED]
(Hideyuki Kawashima) wrote:
I appreciate your great
Andrew,
Your experience is really informative. Thanks for giving me such a
really precious information. Since I am a researcher, I rarely faces
on real troubles.
Andrew, I agree with you. UPS is not reliable all the time.
On the other hand, however, disks or raids are also not reliable all the
Tom,
Thanks for your comments !
Let me answer to your beneficial mail.
Indeed, I'm wondering why one needs to hack the Postgres core to throw
away data integrity guarantees;
The motivation of my work is accelerating INSERT/UPDATE without losing
data integrity guarantees. In the first place,
Tom and all,
I apologize destroying the thread information with this topic.
Unfortunately my basic smtp server does not work now and I am writing
all the responses via gmail tonight...
Tom,
Thanks for teaching me about the development assumption of PostgreSQL.
The assumption and my direction
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
Joshua,
Thanks for your comments !
Right. As you pointed out, Sigres cannot recover if UPS fails.
Therefore, I think currently Sigres cannot be used for mission critical
applications.
Sigres keeps data integrity *only when* UPS works.
On the other hand, some users such as researchers of sensor
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.
Joshua,
I appreciate your quick informative reply. And, I also really
appreciate your kind comments. Since I have joined this ML 3 hours ago,
I tried to be polite and slightly nervous. But I was relieved by your
message.
Major topic.
The full_page_writes option is already ignored. In Sigres,
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
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
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
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
[EMAIL PROTECTED] (Hideyuki Kawashima) wrote:
Joshua,
I appreciate your quick informative reply. And, I also really
appreciate your kind comments. Since I have joined this ML 3 hours
ago, I tried to be polite and slightly nervous. But I was relieved
by your message.
Your idea sounds
A long time ago, in a galaxy far, far away, [EMAIL PROTECTED] (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
Gene,
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
On Feb 10, 2007, at 9:33 PM, Christopher Browne wrote:
The fundamental trouble with this mechanism is that a power outage can
instantly turn a database into crud.
One may try to mitigate that problem by supporting the memory device
with multiple power supplies *and* multiple UPSes.
Ask me
Gene [EMAIL PROTECTED] writes:
... just my two cents. on a side note, would putting the wal on a
tmpfs partition give you something similar?
Indeed, I'm wondering why one needs to hack the Postgres core to throw
away data integrity guarantees; there are plenty of ways to do that
already :-(.
Christopher Browne wrote:
[EMAIL PROTECTED] (Hideyuki Kawashima) wrote:
Joshua,
I appreciate your quick informative reply. And, I also really
appreciate your kind comments. Since I have joined this ML 3 hours
ago, I tried to be polite and slightly nervous. But I was relieved
by your
Tom Lane wrote:
Gene [EMAIL PROTECTED] writes:
... just my two cents. on a side note, would putting the wal on a
tmpfs partition give you something similar?
Indeed, I'm wondering why one needs to hack the Postgres core to throw
away data integrity guarantees; there are plenty of ways to do
Joshua D. Drake [EMAIL PROTECTED] writes:
Tom Lane wrote:
I'd like to see a clear explanation of what assumptions are being made
and why they represent a useful case.
Absolutely agreed there.
Just to be clear: I believe our current assumptions can be stated as
Postgres will not lose data if
40 matches
Mail list logo
