Re: Oh, this is embarrassing: init file logic is still broken
От | Tatsuo Ishii |
---|---|
Тема | Re: Oh, this is embarrassing: init file logic is still broken |
Дата | |
Msg-id | 20150625.172025.1041054706789821368.t-ishii@sraoss.co.jp обсуждение исходный текст |
Ответ на | Re: Oh, this is embarrassing: init file logic is still broken (Josh Berkus <josh@agliodbs.com>) |
Ответы |
Re: Oh, this is embarrassing: init file logic is still broken
|
Список | pgsql-hackers |
> On 06/23/2015 04:44 PM, Tom Lane wrote: >> Chasing a problem identified by my Salesforce colleagues led me to the >> conclusion that my commit f3b5565dd ("Use a safer method for determining >> whether relcache init file is stale") is rather borked. It causes >> pg_trigger_tgrelid_tgname_index to be omitted from the relcache init file, >> because that index is not used by any syscache. I had been aware of that >> actually, but considered it a minor issue. It's not so minor though, >> because RelationCacheInitializePhase3 marks that index as nailed for >> performance reasons, and includes it in NUM_CRITICAL_LOCAL_INDEXES. >> That means that load_relcache_init_file *always* decides that the init >> file is busted and silently(!) ignores it. So we're taking a nontrivial >> hit in backend startup speed as of the last set of minor releases. > > OK, this is pretty bad in its real performance effects. On a workload > which is dominated by new connection creation, we've lost about 17% > throughput. Are we going to release 9.4.5 etc. soon? Best regards, -- Tatsuo Ishii SRA OSS, Inc. Japan English: http://www.sraoss.co.jp/index_en.php Japanese:http://www.sraoss.co.jp
В списке pgsql-hackers по дате отправления: