Re: Load distributed checkpoint V3 - Mailing list pgsql-patches

From Takayuki Tsunakawa
Subject Re: Load distributed checkpoint V3
Date
Msg-id 007a01c77821$b04fc460$19527c0a@OPERAO
Whole thread Raw
In response to Load distributed checkpoint V3  (ITAGAKI Takahiro <itagaki.takahiro@oss.ntt.co.jp>)
Responses Re: Load distributed checkpoint V3
List pgsql-patches
From: "Greg Smith" <gsmith@gregsmith.com>
> If you compare how Oracle handles their writes and checkpoints to
the
> Postgres code, it's obvious they have a different architecture that
> enables them to support sync writing usefully.  I'd recommend the
Database
> Writer Process section of
>
http://www.lc.leidenuniv.nl/awcourse/oracle/server.920/a96524/c09procs.htm
> as an introduction for those not familiar with that; it's
interesting
> reading for anyone tinking with background writer code.

Hmm... what makes you think that sync writes is useful for Oracle and
not for PostgreSQL? The process architecture is similar; bgwriter
performs most of writes in PostgreSQL, while DBWn performs all writes
in Oracle. The difference is that Oracle can assure crash recovery
time by writing dirby buffers periodically in the order of their LSN.


> It would be great to compare performance of the current PostgreSQL
code
> with a fancy multiple background writer version using the latest
sync
> methods or AIO; there have actually been multiple updates to improve
> O_SYNC writes within Linux during the 2.6 kernel series that make
this
> more practical than ever on that platform.  But as you've already
seen,
> the performance hurdle to overcome is significant, and it would have
to be
> optional as a result.  When you add all this up--have to keep the
current
> non-sync writes around as well, need to redesign the whole
background
> writer/checkpoint approach around the idea of sync writes, and the
> OS-specific parts that would come from things like AIO--it gets real
> messy.  Good luck drumming up support for all that when the initial
> benchmarks suggest it's going to be a big step back.

I agree with you in that write method has to be optional until there's
enough data from the field that help determine which is better.

... It's a pity not to utilize async I/O and Josh-san's offer. I hope
it will be used some day. I think OS developers have evolved async I/O
for databases.





pgsql-patches by date:

Previous
From: Greg Smith
Date:
Subject: Re: Load distributed checkpoint V3
Next
From: Gregory Stark
Date:
Subject: Re: Packed Varlena Update (v21)