hi,
On Wed, Nov 30, 2011 at 1:37 AM, YAMAMOTO Takashi
y...@mwd.biglobe.ne.jp wrote:
Yes, I would expect that. What kind of increase are you seeing? Is
it causing a problem for you, or are you just making an observation?
i was curious because my application uses async commits mainly to
Hi Robert,
On Wednesday, November 30, 2011 02:10:00 PM Robert Haas wrote:
On Wed, Nov 30, 2011 at 1:37 AM, YAMAMOTO Takashi
y...@mwd.biglobe.ne.jp wrote:
Yes, I would expect that. What kind of increase are you seeing? Is
it causing a problem for you, or are you just making an
On Thu, Dec 1, 2011 at 4:09 AM, Andres Freund and...@anarazel.de wrote:
Oh, that's interesting. Why do you want to avoid frequent fsyncs? I
thought the point of synchronous_commit=off was to move the fsyncs to
the background, but not necessarily to decrease the frequency.
Is that so? If it
On Thursday, December 01, 2011 03:11:43 PM Robert Haas wrote:
On Thu, Dec 1, 2011 at 4:09 AM, Andres Freund and...@anarazel.de wrote:
Oh, that's interesting. Why do you want to avoid frequent fsyncs? I
thought the point of synchronous_commit=off was to move the fsyncs to
the background,
On Thu, Dec 1, 2011 at 6:11 AM, Robert Haas robertmh...@gmail.com wrote:
One possible downside of trying to kick off the fsync more quickly is
that if there are a continuous stream of background fsyncs going on, a
process that needs to do an XLogFlush in the foreground (i.e. a
On Thu, Dec 1, 2011 at 9:58 AM, Jeff Janes jeff.ja...@gmail.com wrote:
Waiting until the other one completes is how it currently is
implemented, but is it necessary from a correctness view? It seems
like the WALWriteLock only needs to protect the write, and not the
sync (assuming the sync
hi,
On Tue, Nov 29, 2011 at 1:42 AM, YAMAMOTO Takashi
y...@mwd.biglobe.ne.jp wrote:
On Mon, Nov 7, 2011 at 5:26 PM, Simon Riggs si...@2ndquadrant.com wrote:
5. Make the WAL writer more responsive, maybe using latches, so that
it doesn't take as long for the commit record to make it out to
On Wed, Nov 30, 2011 at 1:37 AM, YAMAMOTO Takashi
y...@mwd.biglobe.ne.jp wrote:
Yes, I would expect that. What kind of increase are you seeing? Is
it causing a problem for you, or are you just making an observation?
i was curious because my application uses async commits mainly to
avoid
On Tue, Nov 29, 2011 at 1:42 AM, YAMAMOTO Takashi
y...@mwd.biglobe.ne.jp wrote:
On Mon, Nov 7, 2011 at 5:26 PM, Simon Riggs si...@2ndquadrant.com wrote:
5. Make the WAL writer more responsive, maybe using latches, so that
it doesn't take as long for the commit record to make it out to disk.
On Tue, Nov 8, 2011 at 1:59 AM, Simon Riggs si...@2ndquadrant.com wrote:
Please continue to expect that, I just haven't finished it yet...
OK.
So here's the deal: this is an effective, mostly automatic solution to
the performance problem noted in the original post. For example, at
32 clients,
On Mon, Nov 7, 2011 at 9:31 AM, Robert Haas robertmh...@gmail.com wrote:
So, what could we do about this? Ideas:
1. Set the hint bits right away, and avoid letting the page be flushed
to disk until the commit record is durably on disk (by bumping the
page LSN?).
2. Improve CLOG concurrency
Robert Haas robertmh...@gmail.com writes:
SetHintBits() can't set HEAP_XMIN_COMMITTED or HEAP_XMAX_COMMITTED
hints until the commit record has been durably flushed to disk. It
turns out that can cause a major performance regression on systems
with many CPU cores.
It seems to me that you've
On Mon, Nov 7, 2011 at 8:31 AM, Robert Haas robertmh...@gmail.com wrote:
I've long considered synchronous_commit=off to be one of our best
performance features. Certainly, it's not applicable in every
situation, but there are many applications where losing a second or so
worth of transactions
On Mon, Nov 7, 2011 at 9:12 AM, Tom Lane t...@sss.pgh.pa.us wrote:
Robert Haas robertmh...@gmail.com writes:
SetHintBits() can't set HEAP_XMIN_COMMITTED or HEAP_XMAX_COMMITTED
hints until the commit record has been durably flushed to disk. It
turns out that can cause a major performance
On Mon, Nov 7, 2011 at 10:12 AM, Tom Lane t...@sss.pgh.pa.us wrote:
Robert Haas robertmh...@gmail.com writes:
SetHintBits() can't set HEAP_XMIN_COMMITTED or HEAP_XMAX_COMMITTED
hints until the commit record has been durably flushed to disk. It
turns out that can cause a major performance
On Mon, Nov 7, 2011 at 2:45 PM, Robert Haas robertmh...@gmail.com wrote:
2. Improve CLOG concurrency or performance in some way so that
consulting it repeatedly doesn't slow us down so much.
We should also ask what makes the clog slow. I think it shows physical
contention as well as logical
On Mon, Nov 7, 2011 at 12:26 PM, Simon Riggs si...@2ndquadrant.com wrote:
5. Make the WAL writer more responsive, maybe using latches, so that
it doesn't take as long for the commit record to make it out to disk.
I'm working on this already as part of the update for power
reduction/group
On Mon, Nov 7, 2011 at 9:25 AM, Merlin Moncure mmonc...@gmail.com wrote:
On Mon, Nov 7, 2011 at 8:31 AM, Robert Haas robertmh...@gmail.com wrote:
I've long considered synchronous_commit=off to be one of our best
performance features. Certainly, it's not applicable in every
situation, but
On Mon, Nov 7, 2011 at 1:08 PM, Merlin Moncure mmonc...@gmail.com wrote:
Thinking about this more, the backend local cache approach is probably
going to be useless in terms of addressing this problem -- mostly due
to the fact that the cache is, well, local. Even if backend A takes
the time to
On Mon, Nov 7, 2011 at 12:19 PM, Robert Haas robertmh...@gmail.com wrote:
On Mon, Nov 7, 2011 at 1:08 PM, Merlin Moncure mmonc...@gmail.com wrote:
Thinking about this more, the backend local cache approach is probably
going to be useless in terms of addressing this problem -- mostly due
to the
On Mon, Nov 7, 2011 at 5:26 PM, Simon Riggs si...@2ndquadrant.com wrote:
5. Make the WAL writer more responsive, maybe using latches, so that
it doesn't take as long for the commit record to make it out to disk.
I'm working on this already as part of the update for power
reduction/group
On Mon, Nov 7, 2011 at 6:33 PM, Simon Riggs si...@2ndquadrant.com wrote:
On Mon, Nov 7, 2011 at 5:26 PM, Simon Riggs si...@2ndquadrant.com wrote:
5. Make the WAL writer more responsive, maybe using latches, so that
it doesn't take as long for the commit record to make it out to disk.
I'm
On Nov 7, 2011, at 9:35 PM, Robert Haas robertmh...@gmail.com wrote:
On Mon, Nov 7, 2011 at 6:33 PM, Simon Riggs si...@2ndquadrant.com wrote:
On Mon, Nov 7, 2011 at 5:26 PM, Simon Riggs si...@2ndquadrant.com wrote:
5. Make the WAL writer more responsive, maybe using latches, so that
it
On Tue, Nov 8, 2011 at 2:35 AM, Robert Haas robertmh...@gmail.com wrote:
What I was expecting you to do is eliminate
wal_writer_delay altogether and drive the wakeups entirely off of the
latch.
Please continue to expect that, I just haven't finished it yet...
--
Simon Riggs
24 matches
Mail list logo
