public inbox for [email protected]
help / color / mirror / Atom feedFrom: Michael Paquier <[email protected]>
To: Alena Rybakina <[email protected]>
Cc: Guillaume Lelarge <[email protected]>
Cc: Bertrand Drouvot <[email protected]>
Cc: PostgreSQL Hackers <[email protected]>
Subject: Re: Add parallel columns for seq scan and index scan on pg_stat_all_tables and _indexes
Date: Mon, 7 Oct 2024 09:41:36 +0900
Message-ID: <[email protected]> (raw)
In-Reply-To: <[email protected]>
References: <CAECtzeXXuMkw-RVGTWvHGOJsmFdsRY+jK0ndQa80sw46y2uvVQ@mail.gmail.com>
<[email protected]>
<CAECtzeUJ2y1yZcdcHfzkFX=CCYV7RwnHfwhpHyTe-hrzaUgm0g@mail.gmail.com>
<[email protected]>
<CAECtzeXi2b+hc-=xFUSN2phvmenivOz0CO9fi9pLaaObpAVWHA@mail.gmail.com>
<[email protected]>
<CAECtzeVdwg1tA53RABSMs9wOCAn6ROWo4LfDstA=bistGLMZ2A@mail.gmail.com>
<CAECtzeXUA-gv6Y5_+-y+LHkcYXuxSFHhKgHeMd9KWRnH+47Ttg@mail.gmail.com>
<[email protected]>
On Mon, Oct 07, 2024 at 12:43:18AM +0300, Alena Rybakina wrote:
> Maybe I'm not aware of the whole context of the thread and maybe my
> questions will seem a bit stupid, but honestly
> it's not entirely clear to me how this statistics will help to adjust the
> number of parallel workers.
> We may have situations when during overestimation of the cardinality during
> query optimization a several number of parallel workers were unjustifiably
> generated and vice versa -
> due to a high workload only a few number of workers were generated.
> How do we identify such cases so as not to increase or decrease the number
> of parallel workers when it is not necessary?
Well. For spiky workloads, only these numbers are not going to help.
If you can map them with the number of times a query related to these
tables has been called, something that pg_stat_statements would be
able to show more information about.
FWIW, I have doubts that these numbers attached to this portion of the
system are always useful. For OLTP workloads, parallel workers would
unlikely be spawned because even with JOINs we won't work with a high
number of tuples that require them. This could be interested with
analytics, however complex query sequences mean that we'd still need
to look at all the plans involving the relations where there is an
unbalance of planned/spawned workers, because these can usually
involve quite a few gather nodes. At the end of the day, it seems to
me that we would still need data that involves statements to track
down specific plans that are starving. If your application does not
have that many statements, looking at individial plans is OK, but if
you have hundreds of them to dig into, this is time-consuming and
stats at table/index level don't offer data in terms of stuff that
stands out and needs adjustments.
And this is without the argument of bloating more the stats entries
for each table, even if it matters less now that these stats are in
shmem lately.
--
Michael
Attachments:
[application/pgp-signature] signature.asc (833B, ../[email protected]/2-signature.asc)
download
view thread (7+ messages) latest in thread
reply
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: [email protected]
Cc: [email protected], [email protected], [email protected], [email protected], [email protected]
Subject: Re: Add parallel columns for seq scan and index scan on pg_stat_all_tables and _indexes
In-Reply-To: <[email protected]>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by agora; see mirroring instructions
for how to clone and mirror all data and code used for this inbox