On Thu, Dec 10, 2015 at 12:55 PM, Greg Stark <st...@mit.edu> wrote: > 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?
No. > 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. All true, but irrelevant. The places I just mentioned wouldn't get called during recovery. They're only invoked from queries. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
