Re: Why doesn't GiST VACUUM require a super-exclusive lock, like nbtree VACUUM?
| От | Michail Nikolaev |
|---|---|
| Тема | Re: Why doesn't GiST VACUUM require a super-exclusive lock, like nbtree VACUUM? |
| Дата | |
| Msg-id | CANtu0oiqovQy3jvbv+Uqv6cjTXLgePbTRRL_=Dr3+=dZTSfXKw@mail.gmail.com обсуждение исходный текст |
| Ответ на | Re: Why doesn't GiST VACUUM require a super-exclusive lock, like nbtree VACUUM? (Matthias van de Meent <boekewurm+postgres@gmail.com>) |
| Список | pgsql-hackers |
Hello!
Sorry, I should have expressed my thoughts in more detail, as they don't matter as much as the time you took to answer.
>I don't quite read it as covering IOS. To me, the comment is more
> along the lines of (extensively extended): My idea was just to add a few more details about the locking rule, such as:
* safe to apply LP_DEAD hints to the page later. This allows us to drop
* the pin for MVCC scans (except in cases of index-only scans due to XXX), which allows vacuum to avoid blocking.
> I think this "MVCC scan" even means non-IOS scan
Maybe, but I think it’s better to clarify that, since IOS scans still use the MVCC snapshot. For me, a non-MVCC scan is something like SnapshotSelf or SnapshotDirty.
> Why would it be incorrect or invalid to kill items in an index-only scan?
Oh, I was comparing the logic to that of btree and somehow made a logical error in my conclusions. But at least I hope I got some useful thoughts out of it - since we have a pin during gistkillitems in the case of IOS, we can ignore the "if (BufferGetLSNAtomic(buffer) != so->curPageLSN)" check in that case because vacuum is locked.
It is not a compensation for a performance penalty caused by buffer pin during IOS, but at least something.
I hope this time my conclusions are correct :)
Thanks,
Mikhail.
В списке pgsql-hackers по дате отправления: