On Tue, 2008-10-28 at 12:16 -0400, Tom Lane wrote: > Simon Riggs <[EMAIL PROTECTED]> 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.com PostgreSQL Training, Services and Support -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
