Comments on the HOT design
От | Heikki Linnakangas |
---|---|
Тема | Comments on the HOT design |
Дата | |
Msg-id | 469DEE5B.4070404@enterprisedb.com обсуждение исходный текст |
Ответы |
Re: Comments on the HOT design
Re: Comments on the HOT design |
Список | pgsql-hackers |
Here's what I think we should do to the HOT patch: 1. Get rid of row-level fragmentation and handling dealing with LP_DELETEd line pointers. Instead, take a vacuum lock opportunistically, and defrag pages using the normal PageRepairFragmentation function. I'm not sure where exactly we would do the pruning and where we would call PageRepairFragmentation. We could do it in heap_release_fetch, but we need some logic to decide when it's helpful and when it's a waste of time. 2. Get rid of separate handling and WAL record types for pruning aborted tuples, ISTM that's no longer needed with the simplified pruning method. 3. Currently, the patch has a separate code path for pruning pages in VACUUM FULL, which removes any DEAD tuples in the middle of chains, and fixes the ctid/xmin of the previous/next tuple to keep the chain valid. Instead, we should just prune all the preceding tuples in the chain, since they're in fact dead as well. Our simplistic check with OldestXmin just isn't enough to notice that. I think we can share most of the code between normal pruning and VACUUM FULL, which is good because the VACUUM FULL codepath is used very seldom, so if there's any bugs in there they might go unnoticed for a long time. 4. Write only one WAL record per pruned page, instead of one per update chain. I've done some experimenting on those items, producing several badly broken versions of the patch partly implementing those ideas. It looks like the patch size will go down from ~240 kB to ~210 kB, and more importantly, there will be less new concepts and states a tuple can be in and less WAL record types. I know we've been running DBT-2 tests with the patch, and that it's effective in reducing the need to vacuum the big tables which gives better throughput in long runs. But I also know that a lot of people are interested in the potential to avoid CPU overhead of index inserts. We need to run CPU bound benchmarks to measure that effect as well. -- Heikki Linnakangas EnterpriseDB http://www.enterprisedb.com
В списке pgsql-hackers по дате отправления: