Fwd: Avoid endless futile table locks in vacuuming.
От | Jeff Janes |
---|---|
Тема | Fwd: Avoid endless futile table locks in vacuuming. |
Дата | |
Msg-id | CAMkU=1x8VL9bQg4-xUeK6xmQUa48sYm_mUrpNFZhjmgrWFA3Zw@mail.gmail.com обсуждение исходный текст |
Ответ на | Avoid endless futile table locks in vacuuming. (Jeff Janes <jeff.janes@gmail.com>) |
Ответы |
Re: Fwd: Avoid endless futile table locks in vacuuming.
Re: Fwd: Avoid endless futile table locks in vacuuming. |
Список | pgsql-hackers |
Forgetting to CC the list is starting to become a bad habit, sorry. forwarding to list: ---------- Forwarded message ---------- From: Jeff Janes <jeff.janes@gmail.com> Date: Wed, Dec 30, 2015 at 10:03 AM Subject: Re: [HACKERS] Avoid endless futile table locks in vacuuming. To: Tom Lane <tgl@sss.pgh.pa.us> On Dec 29, 2015 4:47 PM, "Tom Lane" <tgl@sss.pgh.pa.us> wrote: > > Jeff Janes <jeff.janes@gmail.com> writes: > > If we are not doing a scan_all and we fail to acquire a clean-up lock on > > the last block, and the last block reports that it needs freezing, then we > > continue on to wait for the clean-up lock. But there is no need, we don't > > really need to freeze the block, and we already know whether it has tuples > > or not without the clean up lock. Couldn't we just set the flag based on > > hastup, then 'continue'? > > Uh, isn't that what my patch is doing? My reading was it does that only if there are no tuples that could be frozen. If there are tuples that could be frozen, it actually does the freezing, even though that is not necessary unless scan_all is true. So like the attached, although it is a bit weird to call lazy_check_needs_freeze if , under !scan_all, we don't actually care about whether it needs freezing but only the hastup. Cheers, Jeff
Вложения
В списке pgsql-hackers по дате отправления: