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

On Fri, Mar 8, 2019 at 7:43 PM Amit Kapila <amit(dot)kapila16(at)gmail(dot)com> wrote:

> Have you done any performance testing of this patch? I mean to say
> now that we added a new stat call for each table, we should see if
> that has any impact. Ideally, that should be compensated by the fact
> that we are now not transferring *fsm files for small relations.

To be precise, it will only call stat if pg_class.relpages is below
the threshold. I suppose I could hack a database where all the
relpages values are wrong, but that seems like a waste of time.

> How
> about constructing a test where all relations are greater than 4 pages
> and then try to upgrade them. We can check for a cluster with a
> different number of relations say 10K, 20K, 50K, 100K.

I did both greater and less than 4 pages for 10k relations. Since
pg_upgrade is O(# relations), I don't see a point in going higher.

First, I had a problem: On MacOS with their "gcc" wrapper around
clang, I got a segfault 11 when compiled with no debugging symbols. I
added "CFLAGS=-O0" and it worked fine. Since this doesn't happen in a
debugging build, I'm not sure how to investigate this. IIRC, this
doesn't happen for me on Linux gcc.

Since it was at least running now, I measured by putting
gettimeofday() calls around transfer_all_new_tablespaces(). I did 10
runs each and took the average, except for patch/1-page case since it
was obviously faster after a couple runs.

5 pages:
master patch
5.59s 5.64s

The variation within the builds is up to +/- 0.2s, so there is no
difference, as expected.

1 page:
master patch
5.62s 4.25s

Clearly, linking is much slower than stat.

--
John Naylor https://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services