Re: decoupling table and index vacuum
От | Robert Haas |
---|---|
Тема | Re: decoupling table and index vacuum |
Дата | |
Msg-id | CA+TgmobnnaUAzVaDk_3=cHTaOTtoHSRzSLokhcHJKX7tNCNQ_w@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: decoupling table and index vacuum (Peter Geoghegan <pg@bowt.ie>) |
Ответы |
Re: decoupling table and index vacuum
|
Список | pgsql-hackers |
On Thu, Apr 22, 2021 at 3:11 PM Peter Geoghegan <pg@bowt.ie> wrote: > I think that everybody's beliefs about VACUUM tend to be correct. It > almost doesn't matter if scenario A is the problem in 90% or cases > versus 10% of cases for scenario B (or vice-versa). What actually > matters is that we have good handling for both. (It's probably some > weird combination of scenario A and scenario B in any case.) I agree strongly with this. In fact, I seem to remember saying similar things to you in the past. If something wins $1 in 90% of cases and loses $5 in 10% of cases, is it a good idea? Well, it depends on how the losses are distributed. If every user can be expected to hit both winning and losing cases with approximately those frequencies, then yes, it's a good idea, because everyone will come out ahead on average. But if 90% of users will see only wins and 10% of users will see only losses, it sucks. That being said, I don't know what this really has to do with the proposal on the table, except in the most general sense. If you're just saying that decoupling stuff is good because different indexes have different needs, I am in agreement, as I said in my OP. It sort of sounded like you were saying that it's not important to try to estimate the number of undeleted dead tuples in each index, which puzzled me, because while knowing doesn't mean everything is wonderful, not knowing it sure seems worse. But I guess maybe that's not what you were saying, so I don't know. I feel like we're in danger of drifting into discussions about whether we're disagreeing with each other rather than, as I would like, focusing on how to design a system for $SUBJECT. -- Robert Haas EDB: http://www.enterprisedb.com
В списке pgsql-hackers по дате отправления: