Re: CLUSTER can change t_len
От | Itagaki Takahiro |
---|---|
Тема | Re: CLUSTER can change t_len |
Дата | |
Msg-id | AANLkTi=NyAK9S8wi2X5uUwzJ2znvt3ajsfVRKun4XiYD@mail.gmail.com обсуждение исходный текст |
Ответ на | CLUSTER can change t_len (Jeff Davis <pgsql@j-davis.com>) |
Ответы |
Re: CLUSTER can change t_len
|
Список | pgsql-hackers |
On Tue, Nov 9, 2010 at 12:44 PM, Jeff Davis <pgsql@j-davis.com> wrote: > See case below. After the item length gets changed, then when reading > the tuple later you get a t_len that includes padding. We can easily find it with pageinspect: \i pageinspect.sql create table foo(i int4); insert into foo values(1); SELECT lp, lp_len FROM heap_page_items(get_raw_page('foo', 0));lp | lp_len ----+-------- 1 | 28 VACUUM FULL foo; SELECT lp, lp_len FROM heap_page_items(get_raw_page('foo', 0));lp | lp_len ----+-------- 1 | 32 > We should document in a comment that t_len can mean multiple things. Or, > we should fix raw_heap_insert() to be consistent with the rest of the > code, which doesn't MAXALIGN the t_len. We have a comment /* be conservative */ in the function, but I'm not sure we actually need the MAXALIGN. However, there would be almost no benefits to keep t_len in small value because we often treat memory in MAXALIGN unit. diff --git a/src/backend/access/heap/rewriteheap.c b/src/backend/access/heap/rewriteheap.c index 0bd1865..0ed94ef 100644 *** a/src/backend/access/heap/rewriteheap.c --- b/src/backend/access/heap/rewriteheap.c *************** raw_heap_insert(RewriteState state, Heap *** 586,592 **** else heaptup = tup; ! len = MAXALIGN(heaptup->t_len); /* be conservative */ /* * If we're gonna fail for oversize tuple, do it right away --- 586,592 ---- else heaptup = tup; ! len = heaptup->t_len; /* * If we're gonna fail for oversize tuple, do it right away -- Itagaki Takahiro
В списке pgsql-hackers по дате отправления: