Re: Add parallel columns for seq scan and index scan on pg_stat_all_tables and _indexes

On Mon, Nov 11, 2024 at 11:06:43AM -0500, Robert Haas wrote:
> But it is unclear to me what sort of tuning we would do based on
> knowing how many of the scans on a certain table or a certain index
> were parallel vs non-parallel. I have not fully reviewed the threads
> linked in the original post; but I did look at them briefly and did
> not immediately see discussion of the specific counters proposed here.
> I also don't see anything in this thread that clearly explains why we
> should want this exact thing. I don't want to make it sound like I
> know that this is useless; I'm sure that Guillaume probably has lots
> of hands-on tuning experience with this stuff that I lack. But the
> reasons aren't clearly spelled out as far as I can see, and I'm having
> some trouble imagining what they are.

Thanks for the summary. My main worry is that these are kind of hard
to act on for tuning when aggregated at relation level (Guillaume,
feel free to counter-argue!). The main point that comes into mind is
that single table scans would be mostly involved with OLTP workloads
or simple joins, where parallel workers are of little use. That could
be much more interesting for analytical-ish workloads with more
complex plan pattern where one or more Gather or GatherMerge nodes are
involved. Still, even in this case I suspect that most users will
finish by looking at plan patterns, and that these counters added for
index or tables would have a limited impact at the end.
--
Michael