On Fri, Mar 8, 2019 at 7:43 PM Amit Kapila <amit.kapila16@gmail.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