| From: | Stephen Frost <sfrost(at)snowman(dot)net> |
|---|---|
| To: | Andres Freund <andres(at)anarazel(dot)de> |
| Cc: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, pgsql-hackers(at)lists(dot)postgresql(dot)org |
| Subject: | Re: More aggressive vacuuming of temporary tables |
| Date: | 2020-09-09 14:14:04 |
| Message-ID: | 20200909141404.GO29590@tamriel.snowman.net |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
Greetings,
* Andres Freund (andres(at)anarazel(dot)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
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Jobin Augustine | 2020-09-09 14:17:22 | Re: unsupportable composite type partition keys |
| Previous Message | Jameson, Hunter 'James' | 2020-09-09 14:08:43 | Re: Fix for parallel BTree initialization bug |