Re: Storing hot members of PGPROC out of the band

Поиск
Список
Период
Сортировка
От Robert Haas
Тема Re: Storing hot members of PGPROC out of the band
Дата
Msg-id CA+TgmoZqb=bXhOT+u9WBpc-ncuV2fE6E=ugTe5tGUzPwZhWzyg@mail.gmail.com
обсуждение исходный текст
Ответ на Re: Storing hot members of PGPROC out of the band  (Jim Nasby <jim@nasby.net>)
Список pgsql-hackers
On Sat, Dec 17, 2011 at 1:00 AM, Jim Nasby <jim@nasby.net> wrote:
> I also wonder how much this throws some previous performance tests into suspicion. If it's not uncommon for
performanceimprovement attempts to shift a bottleneck to a different part of the system and marginally hurt performance
thenwe might be throwing away good performance improvement ideas before we should... 

I think we are (mostly) OK on this point, at least as far as the work
I've been doing.  We've actually had a few previous instances of this
phenomenon - e.g. when I first committed my fastlock patch,
performance actually got worse if you had >40 cores doing read-only
queries, because speeding up the lock manager made it possible for the
spinlock protection SInvalReadLock to mess things up royally.
Nevertheless, we got it committed - and fixed the SInvalReadLock
problem, too.  This one is/was somewhat more subtle, but I'm feeling
pretty good about our chances of making at least some further progress
in time for 9.2.

--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company


В списке pgsql-hackers по дате отправления:

Предыдущее
От: Simon Riggs
Дата:
Сообщение: Re: JSON for PG 9.2
Следующее
От: Marti Raudsepp
Дата:
Сообщение: Re: [PATCH] Caching for stable expressions with constant arguments v3