From: | Mitsumasa KONDO <kondo(dot)mitsumasa(at)gmail(dot)com> |
---|---|
To: | Andres Freund <andres(at)2ndquadrant(dot)com> |
Cc: | Heikki Linnakangas <hlinnakangas(at)vmware(dot)com>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Claudio Freire <klaussfreire(at)gmail(dot)com>, Fabien COELHO <coelho(at)cri(dot)ensmp(dot)fr>, Josh Berkus <josh(at)agliodbs(dot)com>, PostgreSQL Developers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: postgresql latency & bgwriter not doing its job |
Date: | 2014-08-31 02:02:48 |
Message-ID: | CADupcHXqXATH6y-BZUu6qGqkfPgbrPi_5mAQ0+8XFoCuMvG=LA@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Hi,
2014-08-31 8:10 GMT+09:00 Andres Freund <andres(at)2ndquadrant(dot)com>:
> On 2014-08-31 01:50:48 +0300, Heikki Linnakangas wrote:
>
> If we're going to fsync between each file, there's no need to sort all the
> > buffers at once. It's enough to pick one file as the target - like in my
> > crude patch - and sort only the buffers for that file. Then fsync that
> file
> > and move on to the next file. That requires scanning the buffers multiple
> > times, but I think that's OK.
>
> I really can't see that working out. Production instances of postgres
> with large shared_buffers settings (say 96GB in one case) have tens of
> thousands of relations (~34500 in the same case). And that's a database
> with a relatively simple schema. I've seen much worse.
Yeah, it is impossible in one checkpointer process. All buffer search cost
is
relatively high than we expect. We need clever algorithm for efficient and
distributed buffer search using multi process or threads.
Regards,
--
Mitsumasa KONDO
From | Date | Subject | |
---|---|---|---|
Next Message | Michael Paquier | 2014-08-31 02:59:07 | Re: PATCH: Allow distdir to be overridden on make command line |
Previous Message | Peter Eisentraut | 2014-08-31 01:37:28 | Re: PATCH: Allow distdir to be overridden on make command line |