| From: | "k(dot)jamison(at)fujitsu(dot)com" <k(dot)jamison(at)fujitsu(dot)com> |
|---|---|
| To: | "tsunakawa(dot)takay(at)fujitsu(dot)com" <tsunakawa(dot)takay(at)fujitsu(dot)com> |
| Cc: | 'Kyotaro Horiguchi' <horikyota(dot)ntt(at)gmail(dot)com>, "amit(dot)kapila16(at)gmail(dot)com" <amit(dot)kapila16(at)gmail(dot)com>, "tgl(at)sss(dot)pgh(dot)pa(dot)us" <tgl(at)sss(dot)pgh(dot)pa(dot)us>, "andres(at)anarazel(dot)de" <andres(at)anarazel(dot)de>, "robertmhaas(at)gmail(dot)com" <robertmhaas(at)gmail(dot)com>, "tomas(dot)vondra(at)2ndquadrant(dot)com" <tomas(dot)vondra(at)2ndquadrant(dot)com>, "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org> |
| Subject: | RE: [Patch] Optimize dropping of relation buffers using dlist |
| Date: | 2020-10-22 02:06:43 |
| Message-ID: | OSBPR01MB2341711E9BB75892B5779CC5EF1D0@OSBPR01MB2341.jpnprd01.prod.outlook.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On Thursday, October 22, 2020 10:34 AM, Tsunakwa-san wrote:
> > I have confirmed that the above comment (commenting out the lines in
> > RelationTruncate) solves the issue for non-recovery case.
> > The attached 0004 patch is just for non-recovery testing and is not
> > included in the final set of patches to be committed for vacuum
> optimization.
>
> I'm relieved to hear that.
>
> As for 0004:
> When testing TRUNCATE, remove the change to storage.c because it was
> intended to troubleshoot the VACUUM test.
I've removed it now.
> What's the change in bufmgr.c for? Is it to be included in 0001 or 0002?
Right. But that should be in 0003. Fixed.
I also fixed the feedback from the previous email:
>(1)
>+ * as the total nblocks for a given fork. The cached value returned by
>
>nblocks -> blocks
> > The table below shows the vacuum execution time for non-recovery case.
> > I've also subtracted the execution time when VACUUM (truncate off) is set.
> >
> > [NON-RECOVERY CASE - VACUUM execution Time in seconds]
> (snip)
> > | 100GB | 65.456 | 1.795 | -3546.57% |
>
> So, the full shared buffer scan for 10,000 relations took about as long as 63
> seconds (= 6.3 ms per relation). It's nice to shorten this long time.
>
> I'll review the patch soon.
Thank you very much for the reviews. Attached are the latest set of patches.
Regards,
Kirk Jamison
| Attachment | Content-Type | Size |
|---|---|---|
| v27-0001-Prevent-invalidating-blocks-in-smgrextend-during.patch | application/octet-stream | 1.1 KB |
| v27-0002-Add-bool-param-in-smgrnblocks-for-cached-blocks.patch | application/octet-stream | 8.8 KB |
| v27-0003-Optimize-DropRelFileNodeBuffers-during-recovery.patch | application/octet-stream | 7.3 KB |
| v27-0004-For-non-recovery-performance-test-case-purposes-.patch | application/octet-stream | 1.7 KB |
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Bharath Rupireddy | 2020-10-22 02:20:01 | Re: A new function to wait for the backend exit after termination |
| Previous Message | Kyotaro Horiguchi | 2020-10-22 02:00:26 | Re: Allow some recovery parameters to be changed with reload |