From: | Pavan Deolasee <pavan(dot)deolasee(at)gmail(dot)com> |
---|---|
To: | Andres Freund <andres(at)2ndquadrant(dot)com> |
Cc: | Guillaume Cottenceau <gc(at)mnc(dot)ch>, pgsql-performance(at)postgresql(dot)org |
Subject: | Re: 9.2.1 & index-only scans : abnormal heap fetches after VACUUM FULL |
Date: | 2012-11-29 12:29:39 |
Message-ID: | CABOikdO+9GW++2TpnrqFfb2h-9SWqk2p1n-iqx61JJbJLhzXBA@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-performance |
On Thu, Nov 29, 2012 at 5:42 PM, Andres Freund <andres(at)2ndquadrant(dot)com>wrote:
> On 2012-11-29 17:20:01 +0530, Pavan Deolasee wrote:
>
> > Now can CLUSTER or VACUUM FULL recreate the visibility map with all bits
> > set to visible, thats an entirely different question. I don't think it
> can,
> > but then I haven't thought through this completely.
>
> It can't set everything to visible as it also copies RECENTLY_DEAD
> tuples and tuples which are not yet visible to other transactions, but
> it should be relatively easy to keep enough information about whether it
> can set the current page to all visible.
Yeah, that looks fairly easy to have. Thinking about it more, now that we
have ability to skip WAL for the case when a table is created and populated
in the same transaction, we could also set the visibility map bits for such
a table (if we are not doing that already). That should be fairly safe too.
Thanks,
Pavan
From | Date | Subject | |
---|---|---|---|
Next Message | Andres Freund | 2012-11-29 12:36:13 | Re: 9.2.1 & index-only scans : abnormal heap fetches after VACUUM FULL |
Previous Message | Andres Freund | 2012-11-29 12:12:28 | Re: 9.2.1 & index-only scans : abnormal heap fetches after VACUUM FULL |