On Sat, Mar 7, 2020 at 9:52 AM Michael Banck <michael.ba...@credativ.de> wrote: > On Mon, Mar 02, 2020 at 06:28:41PM +1300, Thomas Munro wrote: > > * "maintenance_" prefix is like other GUCs that establish (presumably > > larger) limits for processes working on behalf of many user sessions > > I'm a bit skeptical about this - at least in V12 there's only two GUCs > with 'maintenance' in the name: maintenance_work_mem and > max_parallel_maintenance_workers. Both are used for utility commands and > do not apply to regular user queries while (AFAICT) your proposal is not > limited to utility commands. So I think if you name it > 'maintenance'-something, people will assume it only involves VACUUM or > so.
No, the proposal is not for the "maintenance" GUC to affect user queries. The idea is that the "maintenance" GUC would be used for WAL prefetching during recovery[1], index prefetch during VACUUM[2] and probably some other proposed things that are in development relating to background "undo" processing. What these things have in common, as Andres first articulated on thread [2] is that they all deal with a workload that is correlated with the activities of multiple user backends running concurrently. That's the basic idea of the WAL prefetching patch: even though all backends suffer from I/O stalls due to cache misses, usually that's happening concurrently in many backends. A streaming replica that is trying to follow along replaying the write-workload of the primary has to suffer all those stalls sequentially, so I'm trying to recreate some I/O parallelism by looking ahead in the WAL. The theory with the two GUCs is that a user backend should be able to use some I/O parallelism, but a "maintenance" job like the WAL prefetcher should be allowed to use a lot more. That's why the existing VACUUM code mentioned in thread [2] already does "+ 10". Maybe "maintenance" isn't the best word for this, but that's the idea. [1] https://www.postgresql.org/message-id/flat/CA%2BhUKGJ4VJN8ttxScUFM8dOKX0BrBiboo5uz1cq%3DAovOddfHpA%40mail.gmail.com [2] https://www.postgresql.org/message-id/CA%2BTgmoZP-CTmEPZdmqEOb%2B6t_Tts2nuF7eoqxxvXEHaUoBDmsw%40mail.gmail.com
