On 22/05/14 21:05, Jeff Janes wrote: > time and again I need to build indexes. If they are big, that > generates > a lot of WAL data that needs to be replicated to streaming > replication > slaves. Usually these slaves don't lag behind noticeably. So, the > application often reads from them. Well, unless I build indexes and, > thus, create a huge amount of WAL in a short period of time. > > > Are these built CONCURRENTLY? yes > What I'd like to have is something where I can set the max. > bandwidth > with which the index generating backend may generate WAL data. I > seem to > remember to have seen a discussion about something similar but can't > recall where. > > Is there anything I can do about that problem in 9.3 or 9.4? > > I already have a function that waits for the streaming slaves to > catch > up. But that mitigates the problem only at a very crude level. > I'd like > to be able to set that bandwidth to, say, 10mbit/sec. Then I can > be sure > that all my replicas are fine. How long the index creation > takes, does > not matter. > > > This does not appear the domain of PostgreSQL as much as the domain > of your OS and network layer. > > > The OS and network have little choice but to process the WAL in the > order it is generated. If you want to throttle the generation of WAL > by background maintenance operations so they don't interfere with the > processing of WAL generated by bread-and-butter transaction processing, > that is something that only PostgreSQL can do. That's what I want, to throttle the rate at which WAL is generated by maintenance operations. I take it, there is no such thing by now. Would it be a useful addition? I am not sure if I have the time to implement it. I have had a cursory look at the code before, just to find out how things work, but never changed something. What do you think, is it complicated to implement? Torsten
