Re: Remaining VACUUM patches
От | Heikki Linnakangas |
---|---|
Тема | Re: Remaining VACUUM patches |
Дата | |
Msg-id | 462696BD.6090808@enterprisedb.com обсуждение исходный текст |
Ответ на | Remaining VACUUM patches (Alvaro Herrera <alvherre@commandprompt.com>) |
Список | pgsql-hackers |
Alvaro Herrera wrote: > There are two additional patches in the VACUUM code. One is Heikki's > patch to recalculate OldestXmin in the vacuum run. > > http://groups.google.es/group/pgsql.patches/browse_thread/thread/b2cfc901534d8990/40ba5b2fbb8f5b91 > (much nicer than our archives because the whole thread is there, not > just month-sized pieces). > > That thread ended without any conclusion; it is said that the patch will > be reconsidered when Simon Riggs' patch about the WAL flushing bug > lands, but I don't know what patch is that. Is it in the patch queue? > Was it already applied? It's in patch queue, not applied. It's the one with title "Bug: Buffer cache is not scan resistant": http://momjian.us/mhonarc/patches/msg00048.html > The problem with the patch is that the DBT-2 test showed decreased > performance, but that was still under investigation. > > What is the status of this? The plan is that I'll rerun the DBT-2 test after the above patch is applied. After that we'll decide if we want the OldestXmin patch or not. > The other patch was ITAGAKI Takahiro's patch to fix n_dead_tuples in > pgstats after VACUUM when there is concurrent update activity. This > patch is still on hold largely because the above patch would cause it to > be a bit obsolete. So I think if we're not going to apply the former, > we should apply this one. I'd like to have the "buffer cache is not scan resistant" patch reviewed first to get the ball rolling on these other patches. The vacuum-related patches are just small tweaks, and they don't conflict with any of the bigger patches in the queue, so there's no reason to rush them, -- Heikki Linnakangas EnterpriseDB http://www.enterprisedb.com
В списке pgsql-hackers по дате отправления: