| From: | Robert Haas <robertmhaas(at)gmail(dot)com> |
|---|---|
| To: | Peter Geoghegan <peter(at)2ndquadrant(dot)com> |
| Cc: | PG Hackers <pgsql-hackers(at)postgresql(dot)org> |
| Subject: | Re: Uh, I change my mind about commit_delay + commit_siblings (sort of) |
| Date: | 2012-05-29 16:58:30 |
| Message-ID: | CA+TgmoaHjVVhcHSaq9=G-R9jYE7SurmF7HSoXFxxM019Omj0mQ@mail.gmail.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On Tue, May 29, 2012 at 12:47 PM, Peter Geoghegan <peter(at)2ndquadrant(dot)com> wrote:
> Why do you think that doing this for all XLogFlush() callsites might
> be problematic?
Well, consider the one in the background writer, for example. That's
just a periodic flush, so I see no benefit in having it acquire the
lock and then wait some more. It already did wait. And what about
the case where we're flushing while holding WALInsertLock because the
buffer's full? Clearly waiting is useless in that case - nobody can
join the group commit for exactly the same reason that we're doing the
flush in the first place: no buffer space.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Robert Haas | 2012-05-29 17:03:36 | Re: pg_basebackup --xlog compatibility break |
| Previous Message | Robert Haas | 2012-05-29 16:55:08 | Re: Bogus nestloop rows estimate in 8.4.7 |