Thread

Re: Disable parallel query by default

Lukas Fittl <lukas@fittl.com> — 2025-05-13T21:05:04Z

On Tue, May 13, 2025 at 4:36 PM Scott Mead <scott@meads.us> wrote:

> I'm looking forward to the upcoming monitoring in e7a9496 (Add two
> attributes to pg_stat_database for parallel workers activity), it will be
> easier to empirically prove that parallel query is being used.  I don't
> think the patch goes far enough though, we really need the ability to
> pinpoint the query and the specific variables used that triggered the
> parallel plan.  When we tell a user that parallel query is in-use and
> suspected, it is almost always met with "no, we don't use that feature".
> Users do not even realize that it's happening and quickly ask for a list of
> all queries that have ever undergone parallel execution.  It's pretty much
> impossible to give an accurate list of these because there is no
> instrumentation available (even in the new patch) to get to the per-query
> level.


Independent of your point at hand, its worth noting that pg_stat_statements
has also gained the two fields parallel_workers_to_launch and
parallel_workers_launched in 18 (see cf54a2c0), that would allow breaking
this down on a per-query basis and getting a better assessment as to which
queries are using parallelism (and whether sufficient parallel workers were
available during execution).

That doesn't help with the aspect of which parameters cause parallel plans
to be used of course (in case a query is flipping between plans), but may
help narrow it down.

Best,
Lukas

-- 
Lukas Fittl