Re: Spread checkpoint sync
От | Simon Riggs |
---|---|
Тема | Re: Spread checkpoint sync |
Дата | |
Msg-id | 1295099721.427.34.camel@ebony обсуждение исходный текст |
Ответ на | Re: Spread checkpoint sync (Greg Smith <greg@2ndquadrant.com>) |
Ответы |
Re: Spread checkpoint sync
|
Список | pgsql-hackers |
On Sat, 2011-01-15 at 05:47 -0500, Greg Smith wrote: > Robert Haas wrote: > > On Tue, Nov 30, 2010 at 3:29 PM, Greg Smith <greg@2ndquadrant.com> wrote: > > > > > One of the ideas Simon and I had been considering at one point was adding > > > some better de-duplication logic to the fsync absorb code, which I'm > > > reminded by the pattern here might be helpful independently of other > > > improvements. > > > > > > > Hopefully I'm not stepping on any toes here, but I thought this was an > > awfully good idea and had a chance to take a look at how hard it would > > be today while en route from point A to point B. The answer turned > > out to be "not very", so PFA a patch that seems to work. I tested it > > by attaching gdb to the background writer while running pgbench, and > > it eliminate the backend fsyncs without even breaking a sweat. > > > > No toe damage, this is great, I hadn't gotten to coding for this angle > yet at all. Suffering from an overload of ideas and (mostly wasted) > test data, so thanks for exploring this concept and proving it works. No toe damage either, but are we sure we want the de-duplication logic and in this place? I was originally of the opinion that de-duplicating the list would save time in the bgwriter, but that guess was wrong by about two orders of magnitude, IIRC. The extra time in the bgwriter wasn't even noticeable. -- Simon Riggs http://www.2ndQuadrant.com/books/PostgreSQL Development, 24x7 Support, Training and Services
В списке pgsql-hackers по дате отправления: