Re: In pg_upgrade, copy fsm, vm, and extent files by checking for fi

On Wed, Nov 14, 2012 at 06:28:41PM -0500, Bruce Momjian wrote:
> On Wed, Nov 14, 2012 at 06:15:30PM -0500, Tom Lane wrote:
> > Bruce Momjian <bruce@momjian.us> writes:
> > > On Wed, Nov 14, 2012 at 05:39:29PM -0500, Tom Lane wrote:
> > >> You would have been better off keeping the array and sorting it so you
> > >> could use binary search, instead of passing the problem off to the
> > >> filesystem.
> >
> > > Well, testing showed using open() was a big win.
> >
> > ... on the filesystem you tested on.  I'm concerned that it might not
> > look so good on other platforms.
>
> True. I am on ext3.  So I need to generate a proof-of-concept patch and
> have others test it?

OK, test patch attached.  The patch will only work if your database uses
a single tablespace.  Doing multiple tablespaces seemed too complex for
the test patch.

Here are my results:

        # tables      git    bsearch patch
        1        11.16     10.99
     1000        19.13     19.26
     2000        26.78     27.11
     4000        43.81     42.15
     8000        79.96     77.38
    16000       165.26    162.24
    32000       378.18    368.49
    64000      1083.35   1086.77

As you can see, the bsearch code doesn't see to make much difference.
Sometimes it is faster, other times, slower ---  seem to be just
measurement noise.  This code uses the same method of file lookup as git
head, meaning it looks for specific files rather than patterns ---  this
simplified the bsearch code.

Can anyone see a consistent improvement with the bsearch patch?
Attached is my test shell script.  There is no reason we can't use
bsearch(), except not using it allows us to remove the pg_upgrade
directory listing function.

--
  Bruce Momjian  <bruce@momjian.us>        http://momjian.us
  EnterpriseDB                             http://enterprisedb.com

  + It's impossible for everything to be true. +