Re: query_id, pg_stat_activity, extended query protocol

On Thu, Sep 26, 2024 at 10:55:37PM +0000, Imseih (AWS), Sami wrote:
> Sorry about my last reply. Not sure what happened with my email client.
> Here it is again.

No worries.

> glad to see the asserts are working as expected ad finding these issues.
> I took a look at the patch and tested it. It looks good. My only concern
> is the stability of using min_parallel_table_scan_size = 0. Will it always
> guarantee parallel workers? Can we print some debugging that proves
> a parallel worker was spun up?
>
> Something like this I get with DEBUG1
>
> DEBUG: building index "btree_test_expr_idx" on table "btree_test_expr" with request for 1 parallel workers
>
> What do you think?

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.

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.
--
Michael