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

On Fri, Dec 7, 2018 at 7:25 PM John Naylor <jcnaylor(at)gmail(dot)com> wrote:
>
> On 12/6/18, Amit Kapila <amit(dot)kapila16(at)gmail(dot)com> wrote:
> > On Thu, Dec 6, 2018 at 10:53 PM John Naylor <jcnaylor(at)gmail(dot)com> wrote:
> >>
> >> I've added an additional regression test for finding the right block
> >> and removed a test I thought was redundant. I've kept the test file in
> >> its own schedule.
> >>
> >
> > +# ----------
> > +# fsm does a vacuum, and running it in parallel seems to prevent heap
> > truncation.
> > +# ----------
> > +test: fsm
> > +
> >
> > It is not clear to me from the comment why running it in parallel
> > prevents heap truncation, can you explain what behavior are you seeing
> > and what makes you think that running it in parallel caused it?
>
> One of the tests deletes all records from the relation and vacuums. In
> serial schedule, the heap and FSM are truncated; in parallel they are
> not. Make check fails, since since the tests measure relation size.
> Taking a closer look, I'm even more alarmed to discover that vacuum
> doesn't even seem to remove deleted rows in parallel schedule (that
> was in the last test I added), which makes no sense and causes that
> test to fail. I looked in vacuum.sql for possible clues, but didn't
> see any.
>

I couldn't resist the temptation to figure out what's going on here.
The newly added tests have deletes followed by vacuum and then you
check whether the vacuum has removed the data by checking heap and or
FSM size. Now, when you run such a test in parallel, the vacuum can
sometimes skip removing the rows because there are parallel
transactions open which can see the deleted rows. You can easily
verify this phenomenon by running the newly added tests in one session
in psql when there is another parallel session which has an open
transaction. For example:

Session-1
Begin;
Insert into foo values(1);

Session-2
\i fsm.sql

Now, you should see the results similar to what you are seeing when
you ran the fsm test by adding it to one of the parallel group. Can
you test this at your end and confirm whether my analysis is correct
or not.

So, you can keep the test as you have in parallel_schedule, but
comment needs to be changed. Also, you need to add the new test in
serial_schedule. I have done both the changes in the attached patch,
kindly confirm if this looks correct to you.

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