Re: Recalculating OldestXmin in a long-running vacuum
От | Heikki Linnakangas |
---|---|
Тема | Re: Recalculating OldestXmin in a long-running vacuum |
Дата | |
Msg-id | 45AD17AE.5050603@enterprisedb.com обсуждение исходный текст |
Ответ на | Re: Recalculating OldestXmin in a long-running vacuum (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: Recalculating OldestXmin in a long-running vacuum
|
Список | pgsql-patches |
Tom Lane wrote: > Heikki Linnakangas <heikki@enterprisedb.com> writes: >> It seems to me that we could easily reclaim a bit more dead tuples in a >> vacuum by recalculating the OldestXmin every now and then. > > Doesn't this break relfrozenxid maintenance? Not AFAICS. relfrozenxid is nowadays updated with FreezeLimit. > In any case I'd like to > see some evidence of significant real-world benefit before adding such > a conceptual wart ... I've asked our testers to do a TPC-C run with and without the patch. I'm not expecting it to make a huge difference there, but if you're using a big cost delay, it could make quite a difference for such a simple thing. > The procarray.c change scares me as well; I'm pretty sure the original > coding was intentional. Well, it didn't make much difference before, since OldestXmin was always calculated early in the transaction. -- Heikki Linnakangas EnterpriseDB http://www.enterprisedb.com
В списке pgsql-patches по дате отправления: