Re: query_id, pg_stat_activity, extended query protocol

From: "Imseih (AWS), Sami" <simseih(at)amazon(dot)com>
To: Sami Imseih <samimseih(at)gmail(dot)com>, 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-26 22:55:37
Message-ID: 2C51A286-77C5-49FF-B9F4-9940DE14E2B3@amazon.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: 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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Michael Paquier 2024-09-26 23:17:53 Re: query_id, pg_stat_activity, extended query protocol
Previous Message Sami Imseih 2024-09-26 22:46:27 Re: query_id, pg_stat_activity, extended query protocol