Re: Name for new VACUUM
От | Tom Lane |
---|---|
Тема | Re: Name for new VACUUM |
Дата | |
Msg-id | 26222.996878885@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Re: Name for new VACUUM (Bruce Momjian <pgman@candle.pha.pa.us>) |
Список | pgsql-hackers |
Bruce Momjian <pgman@candle.pha.pa.us> writes: >> INSERTs don't go on the end in the first place, at least not under >> steady-state conditions. That's what the free space map is all about. > But you are assuming you have stuff in the free space map for the table > already, right? I as not assuming that. But that is going to be the normal state of affairs, at least for people who don't reboot their postmasters every few minutes as we developers tend to do. Sure, you can point to situations where lazy VACUUM doesn't do as well as full VACUUM. That's the point of having two implementations isn't it? If we didn't need full VACUUM at all any more, we'd have removed it. The existence of such situations is not justification for claiming that lazy VACUUM isn't an appropriate default behavior. The question is which one is more appropriate for typical installations under typical operating conditions --- and in that sort of scenario there *will* be info in the free space map. Even more to the point, those typical installations do not want exclusive-locked VACUUM. Haven't you paid any attention to the user complaints we've been hearing for the last N years? People want a nonexclusive VACUUM (or no VACUUM at all, but that's not a choice we can offer them now.) That *is* what the typical dbadmin will want to run, and that's why I say it should be the default. If you think that most people will want to stick with exclusive VACUUM, I'd like to see some evidence for that position (so that I know why the time I spent on that project was wasted ;-)). regards, tom lane
В списке pgsql-hackers по дате отправления: