| From: | "Kevin Grittner" <kgrittn(at)mail(dot)com> |
|---|---|
| To: | "Amit Kapila" <amit(dot)kapila(at)huawei(dot)com>,"Josh Berkus" <josh(at)agliodbs(dot)com>,pgsql-hackers(at)postgresql(dot)org |
| Subject: | Re: 9.2.1 & index-only scans : abnormal heap fetches after VACUUM FULL |
| Date: | 2013-01-12 19:14:03 |
| Message-ID: | 20130112191404.255800@gmx.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
Amit Kapila wrote:
> On Thursday, January 10, 2013 6:09 AM Josh Berkus wrote:
>> Surely VACUUM FULL should rebuild the visibility map, and make
>> tuples in the new relation all-visible, no?
Certainly it seems odd to me that VACUUM FULL leaves the the table
in a less-well maintained state in terms of visibility than a
"normal" vacuum. VACUUM FULL should not need to be followed by
another VACUUM.
> I think it cannot made all visible.
I don't think all tuples in the relation are necessarily visible to
all transactions, but the ones which are should probably be flagged
that way.
> How about if any transaction in SSI mode is started before Vacuum
> Full, should it see all tuples.
There are no differences between visibility rules for serializable
transactions (SSI) and repeatable read transactions. It should be
based on whether any snapshots exist which can still see the tuple.
-Kevin
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Heikki Linnakangas | 2013-01-12 20:14:21 | Re: [PATCH] unified frontend support for pg_malloc et al and palloc/pfree mulation (was xlogreader-v4) |
| Previous Message | Tom Lane | 2013-01-12 19:11:27 | Re: Proposal for Allow postgresql.conf values to be changed via SQL [review] |