Re: Eager page freeze criteria clarification
От | Peter Geoghegan |
---|---|
Тема | Re: Eager page freeze criteria clarification |
Дата | |
Msg-id | CAH2-WzkLNuCgu9bcE+QegD6sJ_X6B2x-u9=PPxPNMuGN4LxjzA@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: Eager page freeze criteria clarification (Melanie Plageman <melanieplageman@gmail.com>) |
Ответы |
Re: Eager page freeze criteria clarification
|
Список | pgsql-hackers |
On Mon, Aug 28, 2023 at 7:00 AM Melanie Plageman <melanieplageman@gmail.com> wrote: > To do this, we need to save that insert LSN > somewhere. In the attached WIP patch, I saved it in the table stats, for > now -- knowing that those are not crash-safe. What patch? You didn't actually attach one. > Other discarded heuristic ideas included comparing the next transaction > ID at the end of the vacuum of a relation to the visibility cutoff xid > in the page -- but that wasn't effective for freezing data from bulk > loads. I've long emphasized the importance of designs that just try to avoid disaster. With that in mind, I wonder: have you thought about conditioning page freezing on whether or not there are already some frozen tuples on the page? You could perhaps give some weight to whether or not the page already has at least one or two preexisting frozen tuples when deciding on whether to freeze it once again now. You'd be more eager about freezing pages that have no frozen tuples whatsoever, compared to what you'd do with an otherwise equivalent page that has no unfrozen tuples. Small mistakes are inevitable here. They have to be okay. What's not okay is a small mistake that effectively becomes a big mistake because it gets repeated across each VACUUM operation, again and again, ceaselessly. You can probably be quite aggressive about freezing, to good effect -- provided you can be sure that the downside when it turns out to have been a bad idea is self-limiting, in whatever way. Making more small mistakes might actually be a good thing -- especially if it can dramatically lower the chances of ever making any really big mistakes. VACUUM is not a passive observer of the system. It's just another component in the system. So what VACUUM sees in the table depends in no small part on what previous VACUUMs actually did. It follows that VACUUM should be concerned about how what it does might either help or hinder future VACUUMs. My preexisting frozen tuples suggestion is really just an example of how that principle might be applied. Many variations on the same general idea are possible. There are already various extremely weird feedback loops where what VACUUM did last time affects what it'll do this time. These are vicious circles. So ISTM that there is a lot to be said for disrupting those vicious circles, and even deliberately engineering heuristics that have the potential to create virtuous circles for the right workload. -- Peter Geoghegan
В списке pgsql-hackers по дате отправления: