From: | Clemens Eisserer <linuxhippy(at)gmail(dot)com> |
---|---|
To: | pgsql-bugs(at)postgresql(dot)org |
Subject: | Re: BUG #9161: wal_writer_delay is limited to 10s |
Date: | 2014-02-18 19:03:39 |
Message-ID: | CAFvQSYT65aeC+-KnC7PihZ8GZ6n8OnLLqU1j9weBOV46v-iH3A@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-bugs |
Hi Jeff,
>> > That only happens if an 8 KB boundary has been crossed. Depending on
>> > how
>> > big the records are that he is inserting, you can fit a lot of them in 8
>> > KB. If the records are small, or the table us unlogged so only commit
>> > messages get logged, then you could go many multiples of 10s without
>> > triggering a wake up due to crossing an 8 KB boundary.
Thanks a lot for the in-depth information.
Is the 8KB boundary configureable at compile time?
> /* if we have already flushed that far, consider async commit records */
>
> For this purpose, async commit could mean either commits down with
> synchronous_commit=off, or commits of transactions which touched only
> unlogged tables. So it writes the same 8kb block as last time (but with new
> data at the logical end of the block) and flushes it.
Ah, that explains why my experiments using unlogged tables also
weren't sucessful in avoiding the frequent writes.
Regards, Clemens
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2014-02-18 19:15:34 | Re: BUG #9227: Error on SELECT ROW OVERLAPS ROW with single ROW argument |
Previous Message | Joshua Yanovski | 2014-02-18 18:50:26 | Re: BUG #9227: Error on SELECT ROW OVERLAPS ROW with single ROW argument |