From: | "Pavan Deolasee" <pavan(dot)deolasee(at)gmail(dot)com> |
---|---|
To: | "Tom Lane" <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | josh(at)agliodbs(dot)com, pgsql-hackers(at)postgresql(dot)org, "Simon Riggs" <simon(at)2ndquadrant(dot)com> |
Subject: | Re: Frequent Update Project: Design Overview of HOT Updates |
Date: | 2006-11-10 10:02:35 |
Message-ID: | 2e78013d0611100202scdcc03ke97e7166fde220e3@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On 11/10/06, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us > wrote:
>
> "Pavan Deolasee" <pavan(dot)deolasee(at)gmail(dot)com> writes:
>
> > Yes. The last bit in the t_infomask is used up to mark presence of
> overflow
> > tuple header. But I believe there are few more bits that can be reused.
> > There are three bits available in the t_ctid field as well (since
> ip_posid
> > needs maximum 13 bits).
>
> No, you cannot have those bits --- BLCKSZ is not limited to 8K, and even
> if it were, we will not hold still for sticking flag bits into an
> unrelated datatype.
>
>
BLCKSZ is not limited to 8K, but it is limited to 32K because of lp_off and
lp_len
which are 15 bits in size.
OffsetNumber is limited to (BLCKSZ / sizeof(ItemIdData)). Since
sizeof(ItemIdData) is 4 bytes, MaxOffsetNumber is 8192. So we need only 13
bits to represent the MaxOffsetNumber.
Regards,
Pavan
From | Date | Subject | |
---|---|---|---|
Next Message | Heikki Linnakangas | 2006-11-10 10:12:36 | Re: Frequent Update Project: Design Overview of HOT Updates |
Previous Message | Simon Riggs | 2006-11-10 09:34:57 | Re: Frequent Update Project: Design Overview of HOT |