Re: [HACKERS] Review: GIN non-intrusive vacuum of posting tree
От | Teodor Sigaev |
---|---|
Тема | Re: [HACKERS] Review: GIN non-intrusive vacuum of posting tree |
Дата | |
Msg-id | 6f762594-5261-08e7-663d-97b82ccd0942@sigaev.ru обсуждение исходный текст |
Ответ на | Re: [HACKERS] Review: GIN non-intrusive vacuum of posting tree (Andrew Borodin <borodin@octonica.com>) |
Ответы |
Re: [HACKERS] Review: GIN non-intrusive vacuum of posting tree
|
Список | pgsql-hackers |
> Thank you for your suggestions, do not hesitate to ask any questions, > concurrency and GIN both are very interesting topics. I had a look on patch and found some issue. Look at ginvacuum.c around line 387, function ginVacuumPostingTreeLeaves(): /* * All subtree is empty - just return TRUE to indicate that parent must * do a cleanup. Unlesswe are ROOT an there is way to go upper. */ if(isChildHasVoid && !isAnyNonempy && !isRoot) return TRUE; if(isChildHasVoid) { ... ginScanToDelete(gvs, blkno, TRUE, &root, InvalidOffsetNumber);} In first 'if' clause I see !isRoot, so second if and corresponding ginScanToDelete() could be called only for root in posting tree. If so, it seems to me, it wasn't a good idea to move ginScanToDelete() from ginVacuumPostingTree() and patch should just remove lock for cleanup over ginVacuumPostingTreeLeaves() and if it returns that tree contains empty page then lock the whole posting tree to do ginScanToDelete() work. -- Teodor Sigaev E-mail: teodor@sigaev.ru WWW: http://www.sigaev.ru/
В списке pgsql-hackers по дате отправления: