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