Re: snapshot too old issues, first around wraparound and then more.
От | Andres Freund |
---|---|
Тема | Re: snapshot too old issues, first around wraparound and then more. |
Дата | |
Msg-id | 20210616190637.qbvle77wgjbh2yff@alap3.anarazel.de обсуждение исходный текст |
Ответ на | Re: snapshot too old issues, first around wraparound and then more. (Peter Geoghegan <pg@bowt.ie>) |
Ответы |
Re: snapshot too old issues, first around wraparound and then more.
|
Список | pgsql-hackers |
Hi, On 2021-06-16 10:44:49 -0700, Peter Geoghegan wrote: > On Wed, Jun 16, 2021 at 10:04 AM Tom Lane <tgl@sss.pgh.pa.us> wrote: > > Of course, there's still the question of how VACUUM could cheaply > > apply such info to decide what could be purged. > I would think that it wouldn't really matter inside VACUUM -- it would > only really need to be either an opportunistic pruning or an > opportunistic index deletion thing -- probably both. Most of the time > VACUUM doesn't seem to end up doing most of the work of removing > garbage versions. It's mostly useful for "floating garbage", to use > the proper GC memory management term. I don't fully agree with this. For one, there are workloads where VACUUM removes the bulk of the dead tuples. For another, slowing down VACUUM can cause a slew of follow-on problems, so being careful to not introduce new bottlenecks is important. And I don't think just doing this optimization as part of on-access pruning is reasonable solution. And it's not like making on-access pruning slower is unproblematic either. But as I said nearby, I think the hardest part is figuring out how to deal with ctid chains, not the efficiency of the xid->visibility lookup (or the collection of data necessary for that lookup). Greetings, Andres Freund
В списке pgsql-hackers по дате отправления: