On Wed, Feb 1, 2017 at 10:46:45AM +0530, Pavan Deolasee wrote:
> > contains a WARM tuple. Alternate ideas/suggestions and review of the
> design
> > are welcome!
>
> t_infomask2 contains one last unused bit,
>
>
> Umm, WARM is using 2 unused bits from t_infomask2. You mean there is another
> free bit after that too?
We are obviously going to use several heap or item pointer bits for
WARM, and once we do that it is going to be hard to undo that. Pavan,
are you saying you could do more with WARM if you had more bits? Are we
sure we have given you all the bits we can? Do we want to commit to a
lesser feature because the bits are not available?
> and we could reuse vacuum
> full's bits (HEAP_MOVED_OUT, HEAP_MOVED_IN), but that will need some
> thinking ahead. Maybe now's the time to start versioning relations so
> that we can ensure clusters upgraded to pg10 do not contain any of those
> bits in any tuple headers.
>
>
> Yeah, IIRC old VACUUM FULL was removed in 9.0, which is good 6 year old.
> Obviously, there still a chance that a pre-9.0 binary upgraded cluster exists
> and upgrades to 10. So we still need to do something about them if we reuse
> these bits. I'm surprised to see that we don't have any mechanism in place to
> clear those bits. So may be we add something to do that.
Yeah, good question. :-( We have talked about adding some page,
table, or cluster-level version number so we could identify if a given
tuple _could_ be using those bits, but never did it.
> I'd some other ideas (and a patch too) to reuse bits from t_ctid.ip_pos given
> that offset numbers can be represented in just 13 bits, even with the maximum
> block size. Can look at that if it comes to finding more bits.
OK, so it seems more bits is not a blocker to enhancements, yet.
-- Bruce Momjian <bruce@momjian.us> http://momjian.us EnterpriseDB
http://enterprisedb.com
+ As you are, so once was I. As I am, so you will be. +
+ Ancient Roman grave inscription +
