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. +
