On Thu, Dec 1, 2011 at 9:58 AM, Jeff Janes 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 method allows those
On Thu, Dec 1, 2011 at 6:11 AM, Robert Haas 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
> synchronous_commit=on transactio
On Thursday, December 01, 2011 03:11:43 PM Robert Haas wrote:
> On Thu, Dec 1, 2011 at 4:09 AM, Andres Freund 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 ne
On Thu, Dec 1, 2011 at 4:09 AM, Andres Freund 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 wouldn't avoi
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
>
> 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
hi,
> On Wed, Nov 30, 2011 at 1:37 AM, YAMAMOTO Takashi
> 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 frequ
On Wed, Nov 30, 2011 at 1:37 AM, YAMAMOTO Takashi
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 frequent fsync. i
hi,
> On Tue, Nov 29, 2011 at 1:42 AM, YAMAMOTO Takashi
> wrote:
>>> On Mon, Nov 7, 2011 at 5:26 PM, Simon Riggs 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 Tue, Nov 29, 2011 at 1:42 AM, YAMAMOTO Takashi
wrote:
>> On Mon, Nov 7, 2011 at 5:26 PM, Simon Riggs 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 alread
On Tue, Nov 8, 2011 at 1:59 AM, Simon Riggs 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, the original test cas
On Tue, Nov 8, 2011 at 2:35 AM, Robert Haas 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 http://www.2ndQu
On Nov 7, 2011, at 9:35 PM, Robert Haas wrote:
> On Mon, Nov 7, 2011 at 6:33 PM, Simon Riggs wrote:
>> On Mon, Nov 7, 2011 at 5:26 PM, Simon Riggs 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 ou
On Mon, Nov 7, 2011 at 6:33 PM, Simon Riggs wrote:
> On Mon, Nov 7, 2011 at 5:26 PM, Simon Riggs 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
On Mon, Nov 7, 2011 at 5:26 PM, Simon Riggs 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 commit/replication
On Mon, Nov 7, 2011 at 12:19 PM, Robert Haas wrote:
> On Mon, Nov 7, 2011 at 1:08 PM, Merlin Moncure 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, lo
On Mon, Nov 7, 2011 at 1:08 PM, Merlin Moncure 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 mark the bit i
On Mon, Nov 7, 2011 at 9:25 AM, Merlin Moncure wrote:
> On Mon, Nov 7, 2011 at 8:31 AM, Robert Haas 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 los
On Mon, Nov 7, 2011 at 12:26 PM, Simon Riggs 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 commit/replication
On Mon, Nov 7, 2011 at 2:45 PM, Robert Haas 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 contention on the lw
On Mon, Nov 7, 2011 at 10:12 AM, Tom Lane wrote:
> Robert Haas 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 CP
On Mon, Nov 7, 2011 at 9:12 AM, Tom Lane wrote:
> Robert Haas 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
On Mon, Nov 7, 2011 at 8:31 AM, Robert Haas 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 is an acceptable
Robert Haas 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 jumped to proposing
On Mon, Nov 7, 2011 at 9:31 AM, Robert Haas 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 or performance i
24 matches
Mail list logo
