Re: Allow parallel plan for referential integrity checks?

From: Frédéric Yhuel <frederic(dot)yhuel(at)dalibo(dot)com>
To: "Imseih (AWS), Sami" <simseih(at)amazon(dot)com>, "pgsql-hackers(at)lists(dot)postgresql(dot)org" <pgsql-hackers(at)lists(dot)postgresql(dot)org>
Subject: Re: Allow parallel plan for referential integrity checks?
Date: 2022-04-14 12:25:13
Message-ID: 4b7849e8-9df7-fbb5-430b-1c36ee7b6abc@dalibo.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On 3/19/22 01:57, Imseih (AWS), Sami wrote:
> I looked at your patch and it's a good idea to make foreign key validation
> use parallel query on large relations.
>
> It would be valuable to add logging to ensure that the ActiveSnapshot and TransactionSnapshot
> is the same for the leader and the workers. This logging could be tested in the TAP test.
>
> Also, inside RI_Initial_Check you may want to set max_parallel_workers to
> max_parallel_maintenance_workers.
>
> Currently the work_mem is set to maintenance_work_mem. This will also require
> a doc change to call out.
>
> /*
> * Temporarily increase work_mem so that the check query can be executed
> * more efficiently. It seems okay to do this because the query is simple
> * enough to not use a multiple of work_mem, and one typically would not
> * have many large foreign-key validations happening concurrently. So
> * this seems to meet the criteria for being considered a "maintenance"
> * operation, and accordingly we use maintenance_work_mem. However, we
>

Hello Sami,

Thank you for your review!

I will try to do as you say, but it will take time, since my daily job
as database consultant takes most of my time and energy.

Best regards,
Frédéric

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Robert Haas 2022-04-14 13:03:08 Re: GSOC'2022: New and improved website for pgjdbc (JDBC) (2022)
Previous Message Euler Taveira 2022-04-14 12:21:27 Re: Logical replication timeout problem