On Wed, Nov 24, 2010 at 2:10 AM, Heikki Linnakangas <heikki.linnakan...@enterprisedb.com> wrote: >> Anything we can do about this? That's a lot of overhead, and it'd be >> a lot worse on a big machine with 8GB of shared_buffers. > > Micro-optimizing that search for the non-zero value helps a little bit > (attached). Reduces the percentage shown by oprofile from about 16% to 12% > on my laptop. > > For bigger gains,
The first optimization that occurred to me was "remove the loop altogether". I could maybe see needing to do something like this if we're recovering from an error, but why do we need to do this (except perhaps to fail an assertion) if we're exiting cleanly? Even a session-lifetime buffer-pin leak would be quite disastrous, one would think. > Now, the other question is if this really matters. Even if we eliminate that > loop in AtProcExit_Buffers altogether, is connect/disconnect still be so > slow that you have to use a connection pooler if you do that a lot? Oh, I'm sure this isn't going to be nearly enough to fix that problem, but every little bit helps; and if we never do the first optimization, we'll never get to #30 or wherever it is that it really starts to move the needle. -- 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
