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 03:54:22
Message-ID: CAA4eK1KADF6K1bagr0--mGv3dMcZ=H_Z-Qtvdfbp5PjaC6PJJA@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Mon, Feb 4, 2019 at 8:47 AM Amit Kapila <amit(dot)kapila16(at)gmail(dot)com> wrote:
>
> On Mon, Feb 4, 2019 at 12:39 AM John Naylor <john(dot)naylor(at)2ndquadrant(dot)com> wrote:
> >
> > On Sun, Feb 3, 2019 at 2:06 PM Amit Kapila <amit(dot)kapila16(at)gmail(dot)com> wrote:
> > >
> > > On Thu, Jan 31, 2019 at 6:03 PM Amit Kapila <amit(dot)kapila16(at)gmail(dot)com> wrote:
> > > This doesn't get applied cleanly after recent commit 0d1fe9f74e.
> > > Attached is a rebased version. I have checked once that the changes
> > > done by 0d1fe9f74e don't impact this patch. John, see if you can also
> > > once confirm whether the recent commit (0d1fe9f74e) has any impact. I
> > > am planning to push this tomorrow morning (IST) unless you or anyone
> > > see any problem with this.
> >
> > Since that commit changes RelationAddExtraBlocks(), which can be
> > induces by your pgbench adjustment upthread, I ran make check with
> > that adjustment in the pgbench dir 300 times without triggering
> > asserts.
> >
> > I also tried to follow the logic in 0d1fe9f74e, and I believe it will
> > be correct without a FSM.
> >
>
> I have just pushed it and buildfarm has shown two failures:
>
> https://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=dromedary&dt=2019-02-04%2002%3A27%3A26
>
> --- /Users/buildfarm/bf-data/HEAD/pgsql.build/contrib/pageinspect/expected/page.out
> 2019-02-03 21:27:29.000000000 -0500
> +++ /Users/buildfarm/bf-data/HEAD/pgsql.build/contrib/pageinspect/results/page.out
> 2019-02-03 21:41:32.000000000 -0500
> @@ -38,19 +38,19 @@
> SELECT * FROM fsm_page_contents(get_raw_page('test_rel_forks', 'fsm', 0));
> fsm_page_contents
> -------------------
> - 0: 39 +
> - 1: 39 +
> - 3: 39 +
> - 7: 39 +
> - 15: 39 +
> - 31: 39 +
> - 63: 39 +
> ..
>
> 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.
>

One more similar failure:
https://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=lapwing&dt=2019-02-04%2003%3A20%3A01

So, basically, this is due to difference in the number of tuples that
can fit on a page. The freespace in FSM for the page is shown
different because of available space on a particular page. This can
vary due to alignment. It seems to me we can't rely on FSM contents
if there are many tuples in a relation. One idea is to get rid of
dependency on FSM contents in this test, can you think of any better
way to have consistent FSM contents across different platforms?

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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Michael Paquier 2019-02-04 04:04:05 Re: Protect syscache from bloating with negative cache entries
Previous Message Alexander Lakhin 2019-02-04 03:53:58 Re: make installcheck-world in a clean environment