Re: WAL Rate Limiting
От | Andres Freund |
---|---|
Тема | Re: WAL Rate Limiting |
Дата | |
Msg-id | 20140116142416.GB4498@alap3.lan обсуждение исходный текст |
Ответ на | Re: WAL Rate Limiting (Robert Haas <robertmhaas@gmail.com>) |
Ответы |
Re: WAL Rate Limiting
|
Список | pgsql-hackers |
On 2014-01-16 09:06:30 -0500, Robert Haas wrote: > > Seems like a really bad name if we are only slowing down some commands - > > that seems to indicate we're slowing down all of them. I think it should be > > something that indicates that it only affects the maintenance commands. > > And why should it only affect the maintenance commands anyway, and who > decides what's a maintenance command? I think implementing it for everything might have some use, but it's a much, much more complex task. You can't simply do rate limiting in XLogInsert() or somesuch - we're holding page locks, buffer pins, other locks... I don't see why that needs to be done in the same feature. I don't really see much difficulty in determining what's a utility command and what not for the purpose of this? All utility commands which create WAL in O(table_size) or worse. > I thought Heroku suggested something like this previously, and their > use case was something along the lines of "we need to slow the system > down enough to do a backup so we can delete some stuff before the disk > fills". For that, it seems likely to me that you would just want to > slow everything down. I think the usecase for this more along the lines of not slowing normal operations or cause replication delays to standbys unduly, while performing maintenance operations on relations. Greetings, Andres Freund -- Andres Freund http://www.2ndQuadrant.com/PostgreSQL Development, 24x7 Support, Training & Services
В списке pgsql-hackers по дате отправления: