Re: Emit fewer vacuum records by reaping removable tuples during pruning
От | Robert Haas |
---|---|
Тема | Re: Emit fewer vacuum records by reaping removable tuples during pruning |
Дата | |
Msg-id | CA+TgmoaKFREz2o+zLfNGE3Z+4zrEfYkvfF3Y=YLL9DemEUTq=A@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: Emit fewer vacuum records by reaping removable tuples during pruning (Melanie Plageman <melanieplageman@gmail.com>) |
Ответы |
Re: Emit fewer vacuum records by reaping removable tuples during pruning
Re: Emit fewer vacuum records by reaping removable tuples during pruning |
Список | pgsql-hackers |
On Wed, Dec 27, 2023 at 11:27 AM Melanie Plageman <melanieplageman@gmail.com> wrote: > Do you have specific concerns about its correctness? I understand it > is an area where we have to be sure we are correct. But, to be fair, > that is true of all the pruning and vacuuming code. I'm kind of concerned that 0002 might be a performance regression. It pushes more branches down into the heap-pruning code, which I think can sometimes be quite hot, for the sake of a case that rarely occurs in practice. I take your point about it improving things when there are no indexes, but what about when there are? And even if there are no adverse performance consequences, is it really worth complicating the logic at such a low level? Also, I find "pronto_reap" to be a poor choice of name. "pronto" is an informal word that seems to have no advantage over something like "immediate" or "now," and I don't think "reap" has a precise, universally-understood meaning. You could call this "mark_unused_now" or "immediately_mark_unused" or something and it would be far more self-documenting, IMHO. -- Robert Haas EDB: http://www.enterprisedb.com
В списке pgsql-hackers по дате отправления: