Re: profiling connection overhead

Robert Haas wrote:
> On Sun, Nov 28, 2010 at 7:15 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> > Robert Haas <robertmhaas(at)gmail(dot)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 <bruce(at)momjian(dot)us> http://momjian.us
EnterpriseDB http://enterprisedb.com

+ It's impossible for everything to be true. +