Re: WIP: Avoid creation of the free space map for small tables

On Tue, Jan 29, 2019 at 5:20 PM Masahiko Sawada <sawada(dot)mshk(at)gmail(dot)com> wrote:
>
> On Tue, Jan 29, 2019 at 9:29 AM Amit Kapila <amit(dot)kapila16(at)gmail(dot)com> wrote:
> >
>
> I'd suspect the alignment of integer. In my environemnt, the tuple
> actual size is 28 bytes but the aligned size is 32 bytes (=
> MAXALIGN(28)), so we can store 226 tuples to single page. But if
> MAXALIGN(28) = 28 then we can store 255 tuples and 1000 tuples fits
> within 4 pages. The MAXALIGN of four buildfarms seem 4 accroding to
> the configure script so MAXALIGN(28) might be 28 on these buildfarms.
>

Good finding. I was also wondering along these lines and wanted to
verify. Thanks a lot. So, this clearly states why we have a second
failure in my email above [1]. I think this means for the fsm test
also we have to be careful when relying on the number of pages in the
test. I think now we have found the reasons and solutions for the
first three problems mentioned in my email [1]. For the problem-4
(Failure on jacana:), I have speculated some theory, but not sure how
can we confirm? Can we try the patch on Jacana before considering the
patch for commit? Is there any other way we can replicate that error?

[1] - https://www.postgresql.org/message-id/CAA4eK1L%3DqWp_bJ5aTc9%2Bfy4Ewx2LPaLWY-RbR4a60g_rupCKnQ%40mail.gmail.com

--
With Regards,
Amit Kapila.
EnterpriseDB: http://www.enterprisedb.com