From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Alvaro Herrera <alvherre(at)commandprompt(dot)com> |
Cc: | Russell Smith <mr-russ(at)pws(dot)com(dot)au>, Josh Berkus <josh(at)agliodbs(dot)com>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Idea for getting rid of VACUUM FREEZE on cold pages |
Date: | 2010-06-02 18:05:31 |
Message-ID: | 9200.1275501931@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Alvaro Herrera <alvherre(at)commandprompt(dot)com> writes:
> The problem is that vacuum doesn't know that a certain part of the table
> is already frozen. It needs to scan it completely anyways. If we had a
> "frozen" map, we could mark pages that are completely frozen and thus do
> not need any vacuuming; but we don't (I don't recall the reasons for
> this. Maybe it's just that no one has gotten around to it, or maybe
> there's something else).
Offhand I think the reason is that you'd have to trust the frozen bit
to be 100% correct (or at least never set to 1 in error). Currently,
both the FSM and visibility forks are just hints, and we won't suffer
data corruption if they're wrong; so we don't get too tense about WAL
logging or fsync'ing updates. I believe Heikki is looking into what
it'd take to make the visibility map 100% reliable, in connection with
the desire for index-only scans. If we get that and the overhead isn't
too terrible maybe we could build a frozen-status map the same way.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Robert Haas | 2010-06-02 18:13:19 | Re: Keepalive for max_standby_delay |
Previous Message | Simon Riggs | 2010-06-02 18:03:50 | Re: Keepalive for max_standby_delay |