On Thu, Dec 10, 2015 at 4:47 PM, Robert Haas <robertmh...@gmail.com> wrote: > > It's not straightforward, but I don't think that's the reason. What > we could do is look at the call sites that use > RelationGetNumberOfBlocks() and change some of them to get the > information some other way instead. I believe get_relation_info() and > initscan() are the primary culprits, accounting for some enormous > percentage of the system calls we do on a read-only pgbench workload. > Those functions certainly know enough to consult a metapage if we had > such a thing.
Would this not run into a chicken and egg problem with recovery? Unless you're going to fsync the meta page whenever the file is extended you'll have to xlog any updates to it and treat the values in memory as authoritative. But when replaying xlog you'll see obsolete inconsistent versions on disk and won't have the correct values in memory either. It seems to me that if you want to fix the linked lists of files that's orthogonal to whether the file lengths on disk are authoritative. You can always keep the lengths or at least the number of files cached and updated in shared memory in a more efficient storage format. -- greg -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
