From: | Robert Haas <robertmhaas(at)gmail(dot)com> |
---|---|
To: | Jeff Janes <jeff(dot)janes(at)gmail(dot)com> |
Cc: | Jim Nasby <Jim(dot)Nasby(at)bluetreble(dot)com>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: optimizing vacuum truncation scans |
Date: | 2015-07-22 13:59:23 |
Message-ID: | CA+Tgmob=B2pdPt2dunD+SY0HzaCFWCxfEvzW3aBGK+Vr+9uc+Q@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Mon, Jun 29, 2015 at 1:54 AM, Jeff Janes <jeff(dot)janes(at)gmail(dot)com> wrote:
> Attached is a patch that implements the vm scan for truncation. It
> introduces a variable to hold the last blkno which was skipped during the
> forward portion. Any blocks after both this blkno and after the last
> inspected nonempty page (which the code is already tracking) must have been
> observed to be empty by the current vacuum. Any other process rendering the
> page nonempty are required to clear the vm bit, and no other process can set
> the bit again during the vacuum's lifetime. So if the bit is still set, the
> page is still empty without needing to inspect it.
Urgh. So if we do this, that forever precludes having HOT pruning set
the all-visible bit. At the least we'd better document that carefully
so that nobody breaks it later. But I wonder if there isn't some
better approach, because I would certainly rather that we didn't
foreclose the possibility of doing something like that in the future.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
From | Date | Subject | |
---|---|---|---|
Next Message | Robert Haas | 2015-07-22 14:00:17 | Re: [PATCH] pg_upgrade fails when postgres/template1 isn't in default tablespace |
Previous Message | Tom Lane | 2015-07-22 13:59:22 | Re: stringify MAKE_SQLSTATE() |