Re: query_id, pg_stat_activity, extended query protocol - Mailing list pgsql-hackers

From Imseih (AWS), Sami
Subject Re: query_id, pg_stat_activity, extended query protocol
Date
Msg-id 2C51A286-77C5-49FF-B9F4-9940DE14E2B3@amazon.com
Whole thread Raw
In response to Re: query_id, pg_stat_activity, extended query protocol  (Sami Imseih <samimseih@gmail.com>)
List pgsql-hackers

> Attached is the patch I am finishing with, with some new tests for

> BRIN and btree to force parallel builds with immutable expressions

> through functions.

 

Sorry about my last reply. Not sure what happened with my email client.

Here it is again.

 

 

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?

 

Regards,

 

Sami

pgsql-hackers by date:

Previous
From: Sami Imseih
Date:
Subject: Re: query_id, pg_stat_activity, extended query protocol
Next
From: Masahiko Sawada
Date:
Subject: Re: Pgoutput not capturing the generated columns