Re: More aggressive vacuuming of temporary tables
От | Stephen Frost |
---|---|
Тема | Re: More aggressive vacuuming of temporary tables |
Дата | |
Msg-id | 20200909141404.GO29590@tamriel.snowman.net обсуждение исходный текст |
Ответ на | Re: More aggressive vacuuming of temporary tables (Andres Freund <andres@anarazel.de>) |
Ответы |
Re: More aggressive vacuuming of temporary tables
|
Список | pgsql-hackers |
Greetings, * Andres Freund (andres@anarazel.de) wrote: > On 2020-08-28 11:46:49 -0400, Tom Lane wrote: > > It strikes me that when we are vacuuming a temporary table (which > > necessarily will be one of our own session), we don't really need > > to care what the global xmin horizon is. If we're not inside a > > user transaction block, then there are no tuples in the table that > > could be in-doubt anymore. Neither are there any snapshots in our > > session that could see any dead tuples. Nor do we give a fig what > > other sessions might think of those tuples. So we could just set > > the xmin cutoff as aggressively as possible, which is to say > > equal to the nextXid counter. While vacuuming a temp table is > > perhaps not something people do very often, I think when they do > > do it they would like us to clean out all the dead tuples not just > > some. > > That seems like a good idea. Agreed. > I've been toying with a patch that introduces more smarts about when a > row is removable, by looking more closely whether a specific row > versions are visible (e.g. in the common case of one old snapshot and > lots of newer rows). But that's orders of magnitude more complicated. So > going for something as simple as this seems like a good idea. I've wondered about this for a long time- very cool that you've found time to actually work on a patch. A couple of different ideas were discussed previously about how to do that kind of a check- mind talking about what method you're using, or perhaps just sharing that patch? :) The potential of such an improvement is huge. Thanks! Stephen
Вложения
В списке pgsql-hackers по дате отправления: