Re: Allow parallel plan for referential integrity checks?
От | Frédéric Yhuel |
---|---|
Тема | Re: Allow parallel plan for referential integrity checks? |
Дата | |
Msg-id | 67ef5e58-cf2e-e5dc-be5c-1723d9ae65f5@dalibo.com обсуждение исходный текст |
Ответ на | Re: Allow parallel plan for referential integrity checks? (Ian Lawrence Barwick <barwick@gmail.com>) |
Ответы |
Re: Allow parallel plan for referential integrity checks?
Re: Allow parallel plan for referential integrity checks? |
Список | 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 по дате отправления: