From: | Kyotaro Horiguchi <horikyota(dot)ntt(at)gmail(dot)com> |
---|---|
To: | noah(at)leadboat(dot)com |
Cc: | pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: mdclose() does not cope w/ FileClose() failure |
Date: | 2020-01-08 01:13:20 |
Message-ID: | 20200108.101320.2034405748744147109.horikyota.ntt@gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
At Wed, 1 Jan 2020 23:46:02 -0800, Noah Misch <noah(at)leadboat(dot)com> wrote in
> On Wed, Dec 25, 2019 at 10:39:32AM +0900, Kyotaro Horiguchi wrote:
> > I'm not sure which is better. If we say we know that
> > repalloc(AllocSetRealloc) doesn't free memory at all, there's no point
> > in calling repalloc for shrinking and we could omit that under the
> > name of optimization. If we say we want to free memory as much as
> > possible, we should call repalloc pretending to believe that that
> > happens.
>
> As long as we free the memory by the end of mdclose(), I think it doesn't
> matter whether we freed memory in the middle of mdclose().
Agreed.
> I ran a crude benchmark that found PathNameOpenFile()+FileClose() costing at
> least two hundred times as much as the repalloc() pair. Hence, I now plan not
> to avoid repalloc(), as attached. Crude benchmark code:
I got about 25 times difference with -O0 and about 50 times with -O2.
(xfs / CentOS8) It's smaller than I intuitively expected but perhaps
50 times difference is large enough.
The patch looks good to me.
regards.
--
Kyotaro Horiguchi
NTT Open Source Software Center
From | Date | Subject | |
---|---|---|---|
Next Message | Stephen Frost | 2020-01-08 01:33:48 | Re: backup manifests |
Previous Message | Tom Lane | 2020-01-08 00:55:17 | Re: Assert failure due to "drop schema pg_temp_3 cascade" for temporary tables and \d+ is not showing any info after drooping temp table schema |