Re: Allow parallel plan for referential integrity checks? - Mailing list pgsql-hackers

From Frédéric Yhuel
Subject Re: Allow parallel plan for referential integrity checks?
Date
Msg-id 67ef5e58-cf2e-e5dc-be5c-1723d9ae65f5@dalibo.com
Whole thread Raw
In response to Re: Allow parallel plan for referential integrity checks?  (Ian Lawrence Barwick <barwick@gmail.com>)
Responses Re: Allow parallel plan for referential integrity checks?  (vignesh C <vignesh21@gmail.com>)
Re: Allow parallel plan for referential integrity checks?  ("Gregory Stark (as CFM)" <stark.cfm@gmail.com>)
List pgsql-hackers

On 12/11/22 06:29, Ian Lawrence Barwick wrote:
> 2022年7月26日(火) 20:58 Frédéric Yhuel <frederic.yhuel@dalibo.com>:
>>
>>
>>
>> On 4/14/22 14:25, Frédéric Yhuel wrote:
>>>
>>>
>>> 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.
>>>
>>
>> Hi,
>>
>> As suggested by Jacob, here is a quick message to say that I didn't find
>> enough time to work further on this patch, but I didn't completely
>> forget it either. I moved it to the next commitfest. Hopefully I will
>> find enough time and motivation in the coming months :-)
> 
> Hi Frédéric
> 
> This patch has been carried forward for a couple more commitfests since
> your message; do you think you'll be able to work on it further during this
> release cycle?
> 

Hi Ian,

I've planned to work on it full time on week 10 (6-10 March), if you 
agree to bear with me. The idea would be to bootstrap my brain on it, 
and then continue to work on it from time to time.

Best regards,
Frédéric



pgsql-hackers by date:

Previous
From: Robert Haas
Date:
Subject: Re: Add sub-transaction overflow status in pg_stat_activity
Next
From: Nathan Bossart
Date:
Subject: Re: add \dpS to psql