Robert Haas wrote: > On Sun, Nov 28, 2010 at 7:15 PM, Tom Lane <t...@sss.pgh.pa.us> wrote: > > Robert Haas <robertmh...@gmail.com> writes: > >> One possible way to get a real speedup here would be to look for ways > >> to trim the number of catcaches. > > > > BTW, it's not going to help to remove catcaches that have a small > > initial size, as the pg_am cache certainly does. ?If the bucket zeroing > > cost is really something to minimize, it's only the caches with the > > largest nbuckets counts that are worth considering --- and we certainly > > can't remove those without penalty. > > Yeah, very true. What's a bit frustrating about the whole thing is > that we spend a lot of time pulling data into the caches that's > basically static and never likely to change anywhere, ever. I bet the > number of people for whom <(int4, int4) has any non-standard > properties is somewhere between slim and none; and it might well be > the case that formrdesc() is faster than reading the relcache init > file, if we didn't need to worry about deviation from canonical. This > is even more frustrating in the hypothetical situation where a backend > can switch databases, because we have to blow away all of these cache > entries that are 99.9% likely to be basically identical in the old and > new databases.
It is very tempting to look at optimizations here, but I am worried we might head down the flat-files solution that caused continual problems in the past. -- Bruce Momjian <br...@momjian.us> http://momjian.us EnterpriseDB http://enterprisedb.com + It's impossible for everything to be true. + -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
