| 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: | Whole Thread | Raw Message | 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 |