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

From: Amit Kapila <amit(dot)kapila16(at)gmail(dot)com>
To: John Naylor <john(dot)naylor(at)2ndquadrant(dot)com>
Cc: Sawada Masahiko <sawada(dot)mshk(at)gmail(dot)com>, Mithun Cy <mithun(dot)cy(at)enterprisedb(dot)com>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: WIP: Avoid creation of the free space map for small tables
Date: 2019-02-04 04:59:06
Message-ID: CAA4eK1+4feqm7VsD=Hy0GY7Lc8CR8iMiSE-Zr_z1=CO8T2Yjiw@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Mon, Feb 4, 2019 at 10:18 AM John Naylor <john(dot)naylor(at)2ndquadrant(dot)com> wrote:
>
> On Mon, Feb 4, 2019 at 4:17 AM Amit Kapila <amit(dot)kapila16(at)gmail(dot)com> wrote:
> > This one seems to be FSM test portability issue (due to different page
> > contents, maybe). Looking into it, John, see if you are around and
> > have some thoughts on it.
>
> Maybe we can use the same plpgsql loop as fsm.sql that exits after 1
> tuple has inserted into the 5th page.
>

Yeah that can also work, but we still need to be careful about the
alignment of that one tuple, otherwise, there will could be different
free space on the fifth page. The probably easier way could be to use
an even number of integers in the table say(int, int). Anyway, for
now, I have avoided the dependency on FSM contents without losing on
coverage of test. I have pushed my latest suggestion in the previous
email.

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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message David Rowley 2019-02-04 05:02:04 Re: ATTACH/DETACH PARTITION CONCURRENTLY
Previous Message Michael Paquier 2019-02-04 04:58:51 Re: Ordered Partitioned Table Scans