Re: Disable parallel query by default
От | Jehan-Guillaume de Rorthais |
---|---|
Тема | Re: Disable parallel query by default |
Дата | |
Msg-id | 20250716135612.15af0991@karst обсуждение исходный текст |
Ответ на | Re: Disable parallel query by default (Jehan-Guillaume de Rorthais <jgdr@dalibo.com>) |
Список | pgsql-hackers |
On Tue, 15 Jul 2025 12:04:12 +0200 Jehan-Guillaume de Rorthais <jgdr@dalibo.com> wrote: > On Mon, 14 Jul 2025 17:25:22 -0400 > Greg Sabino Mullane <htamfids@gmail.com> wrote: > […] > > > Other than picking an arbitrary value (i.e. 5000), any thoughts about how > > > to build a case around a specific value ? > > > > > > Do you have actual examples of queries / situations that are harmed by the > > current settings? Let's start there. > > I did, mid 2024. The customer environment was PostgreSQL 13 and later > PostgreSQL 16 after a major upgrade. > > The application was Nextcloud, ~4000 users per day, 500 per minutes, around > 4000 queries per second on a database of only 40GB. Typical OLTP workload. NB: 500 **active** users per minute. I went back in time to gather as many stats/info as I could from our report, various sysstat numbers and one pgbadger report. I only extracted the top 10 time consuming queries from the report. You'll see it's a basic OLTP workload. The "max_parallel_worker_per_gather=0" as been set the 16th at 10am. Note that I asked our customer to double check the stats from the 22nd were collected from the primary as they are surprisingly low compared to the 15th and 16th. He assures me the production was on this node and the activity was usual (600 concurrent users per minute). See attachments. > Despite connection poolers in the architecture (one per application node), the > number of procs/s on the (dedicated) server was between 60-150+ depending on > the activity. This was hammering the server (a small VM of 8 cores 32GB of > memory). NB: As you can see on the graph, VM has grown from 8 to 16 cores before we turned "max_parallel_worker_per_gather=0", I forgot about that. I'm not stating the PQ should be off by default, but there's definitely something to improve in the costing model, or parallel background worker management I suppose. Regards,
Вложения
В списке pgsql-hackers по дате отправления: