| From: | Sami Imseih <samimseih(at)gmail(dot)com> |
|---|---|
| To: | Michael Paquier <michael(at)paquier(dot)xyz> |
| Cc: | Alexander Lakhin <exclusion(at)gmail(dot)com>, jian he <jian(dot)universality(at)gmail(dot)com>, Anthonin Bonnefoy <anthonin(dot)bonnefoy(at)datadoghq(dot)com>, Andrei Lepikhov <lepihov(at)gmail(dot)com>, kaido vaikla <kaido(dot)vaikla(at)gmail(dot)com>, "pgsql-hackers(at)lists(dot)postgresql(dot)org" <pgsql-hackers(at)lists(dot)postgresql(dot)org> |
| Subject: | Re: query_id, pg_stat_activity, extended query protocol |
| Date: | 2024-09-27 04:01:12 |
| Message-ID: | 04B31A72-7BB4-4BB2-AA3E-9B4F2B611BBE@gmail.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
> I am not sure. The GUCs pretty much enforce this behavior and I doubt
> that these are going to break moving on. Of course they would, but we
> are usually careful enough about that as long as it is possible to
> grep for them. For example see the BRIN case in pageinspect.
Yes, I see pageinspect does the same thing for the BRIN case.
That is probably OK for this case also.
> The usual method for output that we use to confirm parallelism would
> be EXPLAIN. Perhaps a potential target for CREATE INDEX now that it
> supports more modes? I don't know if that's worth it, just throwing
> one idea in the bucket of ideas.
Not sure about EXPLAIN for CREATE INDEX, since it's not a plannable
statement.
Maybe a CREATE INDEX VERBOSE, just Like ANALYZE VERBOSE,
VACUUM VERBOSE, etc. This will show the step that an index
build is on (CONCURRENTLY has many steps), and can also show
if parallel workers are launched for the index build.
--
Sami
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Michael Paquier | 2024-09-27 04:35:23 | Re: pgsql: Implement pg_wal_replay_wait() stored procedure |
| Previous Message | Richard Guo | 2024-09-27 03:53:43 | Re: Eager aggregation, take 3 |