Re: wal_buffers
| От | Peter Geoghegan | 
|---|---|
| Тема | Re: wal_buffers | 
| Дата | |
| Msg-id | CAEYLb_WEVYdar7n+F4VVhJL-pPEGD_hS1BCKfV-FiZykwJF21A@mail.gmail.com обсуждение исходный текст  | 
		
| Ответ на | wal_buffers (Robert Haas <robertmhaas@gmail.com>) | 
| Ответы | 
                	
            		Re: wal_buffers
            		
            		 | 
		
| Список | pgsql-hackers | 
On 19 February 2012 05:24, Robert Haas <robertmhaas@gmail.com> wrote: > I have attached tps scatterplots. The obvious conclusion appears to > be that, with only 16MB of wal_buffers, the buffer "wraps around" with > some regularity: we can't insert more WAL because the buffer we need > to use still contains WAL that hasn't yet been fsync'd, leading to > long stalls. More buffer space ameliorates the problem. Incidentally, I wondered if we could further improve group commit performance by implementing commit_delay with a WaitLatch call, and setting the latch in the event of WAL buffers wraparound (or rather, a queued wraparound request - a segment switch needs WALWriteLock, which the group commit leader holds for a relatively long time during the delay). I'm not really sure how significant a win this might be, though. There could be other types of contention, which could be considerably more significant. I'll try and take a look at it next week. -- Peter Geoghegan http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Training and Services
В списке pgsql-hackers по дате отправления: