| From: | "Pierre C" <lists(at)peufeu(dot)com> |
|---|---|
| To: | "Josh Berkus" <josh(at)agliodbs(dot)com>, "Jeff Janes" <jeff(dot)janes(at)gmail(dot)com> |
| Cc: | pgsql-performance(at)postgresql(dot)org |
| Subject: | Re: Wrong docs on wal_buffers? |
| Date: | 2011-01-05 22:58:32 |
| Message-ID: | op.voux3uooeorkce@apollo13 |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-performance |
> And the risks are rather asymmetric. I don't know of any problem from
> too large a buffer until it starts crowding out shared_buffers, while
> under-sizing leads to the rather drastic performance consequences of
> AdvanceXLInsertBuffer having to wait on the WALWriteLock while holding
> the WALInsertLock,
Suppose you have a large update which generates lots of WAL, some WAL
segment switching will take place, and therefore some fsync()s. If
wal_buffers is small enough that it fills up during the time it takes to
fsync() the previous WAL segment, isn't there a risk that all WAL writes
are stopped, waiting for the end of this fsync() ?
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Kevin Grittner | 2011-01-05 23:10:36 | Re: plan question - query with order by and limit not choosing index depends on size of limit, table |
| Previous Message | Mike Broers | 2011-01-05 22:57:07 | plan question - query with order by and limit not choosing index depends on size of limit, table |