Re: Scaling up deferred unique checks and the after trigger queue
От | Dean Rasheed |
---|---|
Тема | Re: Scaling up deferred unique checks and the after trigger queue |
Дата | |
Msg-id | 8e2dbb700910190948x735b93ebnd55a449784d8c80c@mail.gmail.com обсуждение исходный текст |
Ответ на | Scaling up deferred unique checks and the after trigger queue (Dean Rasheed <dean.a.rasheed@googlemail.com>) |
Ответы |
Re: Scaling up deferred unique checks and the after trigger
queue
Re: Scaling up deferred unique checks and the after trigger queue Re: Scaling up deferred unique checks and the after trigger queue |
Список | pgsql-hackers |
This is a WIP patch to replace the after-trigger queues with TID bitmaps to prevent them from using excessive amounts of memory. Each round of trigger executions is a modified bitmap heap scan. Part of the motivation for this is to scale up the deferrable unique constraints support. I've not done anything to optimise that case directly yet, but this patch will make it easier to switch over to doing a bulk check in that case, and even though it is still executing the trigger for each potential violation, performance for large updates is already greatly improved because of the reduction in the queue's memory footprint. It passes all the regression tests, except for the copy2 test, which sometimes fails, with rows being ordered differently. I believe that the reason for this failure is that during the bitmap heap scan, pages are being pruned, and so the UPDATEs inside later trigger executions start re-using space at the start of the page, whereas the old code moves onto the next page. This could be fixed by changing the test, grouping the COPYs inside a single transaction, to prevent page pruning. - Dean
Вложения
В списке pgsql-hackers по дате отправления: