On Mon, 12 Feb 2024 at 22:17, Greg Sabino Mullane <htamfids@gmail.com> wrote:
Sure will try to test and see how it behaves when the number of simultaneous queries (here 32/4=8 concurrent queries) exceed the max_parallel_workers limit. Though I am expecting the further queries exceeding the limit might get serialized.
Yes - if there are not enough workers available, it will run with a reduced number of workers, including possibly zero. You can see that when you run an explain analyze, it will show you the number of workers it wants and the number if actually was able to get.
Thank you . Got the point.
If these quick queries ran within a certain time frame (say for a duration of ~1hr) and few of the executions ran longer(which might be because of the less parallel workers as the max limit exhausted because of concurrent executions,
OR
It may be because of the change in the execution path for certain execution of the queries.
Is there any way to track those historical executions and be able to find the exact root cause of the slow executions confidently?