Re: Updating FSM on recovery
От | Simon Riggs |
---|---|
Тема | Re: Updating FSM on recovery |
Дата | |
Msg-id | 1225212314.3971.206.camel@ebony.2ndQuadrant обсуждение исходный текст |
Ответ на | Re: Updating FSM on recovery (Tom Lane <tgl@sss.pgh.pa.us>) |
Список | pgsql-hackers |
On Tue, 2008-10-28 at 12:16 -0400, Tom Lane wrote: > Simon Riggs <simon@2ndQuadrant.com> writes: > > Or possibly an XLogInsertDeferred() which just queues up some work so > > the next time we call XLogInsert() it will insert the deferred work as > > well as the main work all in one lock cycle. It would only be usable for > > low priority info like FSM stuff that isn't needed for recovery. Maybe > > we could do that with hints also. > > If it isn't needed for recovery, why would we be logging it at all? You just agreed that the info didn't need to be very accurate. There's a few things on the server that aren't needed for recovery, but it might be useful if they were logged occasionally to give roughly correct values. Contention on WALInsertLock seems to be a problem, yet writing WAL to disk is not a bottleneck. Deferring writing it slightly to allow things to be batched might be one way of smoothing the impact of that type of operation. That might be better than a heuristic method of reducing the number of inserts. -- Simon Riggs www.2ndQuadrant.comPostgreSQL Training, Services and Support
В списке pgsql-hackers по дате отправления: