Skip site navigation (1) Skip section navigation (2)

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

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Bruce Momjian <bruce(at)momjian(dot)us>
Cc: pgsql-committers(at)postgresql(dot)org
Subject: Re: pgsql: In pg_upgrade, copy fsm, vm, and extent files by checking for fi
Date: 2012-11-14 22:39:29
Message-ID: 27789.1352932769@sss.pgh.pa.us (view raw or flat)
Thread:
Lists: pgsql-committerspgsql-hackers
Bruce Momjian <bruce(at)momjian(dot)us> writes:
> In pg_upgrade, copy fsm, vm, and extent files by checking for file
> existence via open(), rather than collecting a directory listing and
> looking up matching relfilenode files with sequential scans of the
> array.  This speeds up pg_upgrade by 2x for a large number of tables,
> e.g. 16k.

Uh ... you replaced a strcmp() with an open()?

I'm prepared to believe that's a win for sufficiently large N, if you
assume that the filesystem is smart enough to have O(1) lookup time
regardless of the directory size ... but that doesn't seem like a very
good assumption, and in any case surely this loses badly for a smaller
number of files.

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.

			regards, tom lane


In response to

Responses

pgsql-hackers by date

Next:From: Robert HaasDate: 2012-11-14 22:46:57
Subject: Re: Add contrib module functions to docs' function index
Previous:From: Robert HaasDate: 2012-11-14 22:38:53
Subject: Re: My first patch! (to \df output)

pgsql-committers by date

Next:From: Bruce MomjianDate: 2012-11-14 22:58:14
Subject: Re: pgsql: In pg_upgrade, copy fsm, vm, and extent files by checking for fi
Previous:From: Bruce MomjianDate: 2012-11-14 22:32:12
Subject: pgsql: In pg_upgrade, copy fsm, vm,and extent files by checking for fi

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group