From: | Andres Freund <andres(at)anarazel(dot)de> |
---|---|
To: | pgsql-hackers(at)postgresql(dot)org,Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | Alvaro Herrera <alvherre(at)2ndquadrant(dot)com> |
Subject: | Re: Metadata about relation creation & full scans. |
Date: | 2017-03-22 15:00:59 |
Message-ID: | 8D2BDDAA-8AC6-4061-8433-CB3D1DFFB220@anarazel.de |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On March 22, 2017 3:54:07 PM GMT+01:00, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>Andres Freund <andres(at)anarazel(dot)de> writes:
>> On 2017-03-22 10:14:14 -0400, Tom Lane wrote:
>>> (2) How you gonna update this in vacuum? It cannot do a
>transactional
>>> update.
>
>> I think we can just do that in a separate transaction, at the tail
>end
>> of vacuum_rel() - if we crash just before that, not that much is
>lost.
>
>Blech. What if someone's queued an exclusive lock request on the
>table?
Point - could do that with a session lock if needed.
>Actually though, maybe you could get away with updating the last-vacuum
>field nontransactionally. I think we're already updating some of the
>other pg_class fields nontransactionally.
We do, reltuples/pages, relfrozenxid and such. That should work too, the whole inplace business ain't pretty, but one more column won't make it much worse.
Andres
--
Sent from my Android device with K-9 Mail. Please excuse my brevity.
From | Date | Subject | |
---|---|---|---|
Next Message | Peter Eisentraut | 2017-03-22 15:21:47 | Re: logical replication access control patches |
Previous Message | Tom Lane | 2017-03-22 15:00:38 | Re: WIP: Faster Expression Processing v4 |