|From:||ilmari(at)ilmari(dot)org (Dagfinn Ilmari =?utf-8?Q?Manns=C3=A5ker?=)|
|To:||Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>|
|Cc:||Andres Freund <andres(at)anarazel(dot)de>, Andreas Karlsson <andreas(at)proxel(dot)se>, pgsql-hackers(at)postgreSQL(dot)org|
|Subject:||Re: Cutting initdb's runtime (Perl question embedded)|
|Views:||Raw Message | Whole Thread | Download mbox | Resend email|
Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> writes:
> Andres Freund <andres(at)anarazel(dot)de> writes:
>> On 2017-04-17 17:49:54 +0100, Dagfinn Ilmari Mannsåker wrote:
>>> I threw Devel::NYTProf at it and picked some more low-hanging fruit.
>> I'm a bit doubtful about improving the performance of genbki at the cost
>> of any sort of complication - it's only executed during the actual
>> build, not during initdb... I don't see much point in doing things like
>> 3) and 4), it's just not worth it imo.
> Yeah, it's only run once per build, or probably even less often than that
> considering we only re-run it when the input files change. I could get
> interested in another 20% reduction in initdb's time, but not genbki's.
Fair enough. I still think 1), 2) and 5) are worthwile code cleanups
regardless of the performance impact. In fact, if we don't care that
much about the performance, we can move the duplicated code in
Gen_fmgrmtab.pl and genbki.pl that turns bki_values into a hash into
Catalogs.pm. That regresses genbki.pl time by ~30ms on my machine.
Revised patch series attached.
- Twitter seems more influential [than blogs] in the 'gets reported in
the mainstream press' sense at least. - Matt McLeod
- That'd be because the content of a tweet is easier to condense down
to a mainstream media article. - Calle Dybedahl
|Next Message||Kyotaro HORIGUCHI||2017-04-18 09:40:13||Re: Quorum commit for multiple synchronous replication.|
|Previous Message||Kyotaro HORIGUCHI||2017-04-18 09:12:38||Re: Passing values to a dynamic background worker|