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
signature.asc
Description: PGP signature
