From: | Tatsuo Ishii <ishii(at)postgresql(dot)org> |
---|---|
To: | josh(at)agliodbs(dot)com |
Cc: | tgl(at)sss(dot)pgh(dot)pa(dot)us, pgsql-hackers(at)postgreSQL(dot)org |
Subject: | Re: Oh, this is embarrassing: init file logic is still broken |
Date: | 2015-06-25 08:20:25 |
Message-ID: | 20150625.172025.1041054706789821368.t-ishii@sraoss.co.jp |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | 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
From | Date | Subject | |
---|---|---|---|
Next Message | Amit Kapila | 2015-06-25 10:37:45 | Re: RFC: replace pg_stat_activity.waiting with something more descriptive |
Previous Message | Michael Paquier | 2015-06-25 08:11:50 | Re: Improving log capture of TAP tests with IPC::Run |