Re: pgsql: In pg_upgrade, copy fsm, vm, and extent files by checking for fi
Tom Lane <tgl@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>
To: Bruce Momjian <bruce@momjian.us>
Cc: pgsql-committers@postgresql.org
Date: 2012-11-14T22:39:29Z
Lists: pgsql-hackers
Bruce Momjian <bruce@momjian.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
Commits
Same data as JSON:
GET /api/v1/messages/:b64id/commits
the thread's linked commits as JSON, with link sources.
API reference →
-
In pg_upgrade, copy fsm, vm, and extent files by checking for file
- 29add0de4920 9.3.0 cited