Re: Dead Space Map version 3 (simplified)
От | Heikki Linnakangas |
---|---|
Тема | Re: Dead Space Map version 3 (simplified) |
Дата | |
Msg-id | 4628DA65.3080208@enterprisedb.com обсуждение исходный текст |
Ответ на | Dead Space Map version 3 (simplified) (ITAGAKI Takahiro <itagaki.takahiro@oss.ntt.co.jp>) |
Ответы |
Re: Dead Space Map version 3 (simplified)
|
Список | pgsql-patches |
ITAGAKI Takahiro wrote: > Attached is an updated DSM patch. I've left the core function of DSM only > and dropped other complicated features in this release. We discussed it a long time ago already, but I really wished the DSM wouldn't need a fixed size shared memory area. It's one more thing the DBA needs to tune manually. It also means we need to have an algorithm for deciding what to keep in the DSM and what to leave out. And I don't see a good way to extend the current approach to implement the index-only-scans that we've been talking about, and the same goes for recovery. :( The way you update the DSM is quite interesting. When a page is dirtied, the BM_DSM_DIRTY flag is set in the buffer descriptor. The corresponding bit in the DSM is set lazily in FlushBuffer whenever BM_DSM_DIRTY is set. That's a clever way to avoid contention on updates. But does it work for tables that have a small hot part that's updated very frequently? That's exactly the scenario where the DSM is the most useful. Hot pages stay in the buffer cache because they're frequently accessed, which means that FlushBuffer isn't getting called for them and the bits in the DSM aren't getting set until checkpoint. This could lead to unnecessary bloating of the hot part. A straightforward fix would be to scan the buffer cache for buffers marked with BM_DSM_DIRTY to update the DSM before starting the vacuum scan. It might not be a problem in practice, but it bothers me that the DSM isn't 100% accurate. You end up having a page with dead tuples on it marked as non-dirty in the DSM at least when a page is vacuumed but there's some RECENTLY_DEAD tuples on it that become dead later on. There might be other scenarios as well. If I'm reading the code correctly, DSM makes no attempt to keep the chunks ordered by block number. If that's the case, vacuum needs to be modified because it currently relies on the fact that blocks are scanned and the dead tuple list is therefore populated in order. -- Heikki Linnakangas EnterpriseDB http://www.enterprisedb.com
В списке pgsql-patches по дате отправления: