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-11-12 04:00:14 |
Message-ID: | OSBPR01MB2341C9B00720565D388E774EEFE70@OSBPR01MB2341.jpnprd01.prod.outlook.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Tuesday, November 10, 2020 3:10 PM, Tsunakawa-san wrote:
> From: Jamison, Kirk/ジャミソン カーク <k(dot)jamison(at)fujitsu(dot)com>
> > So I proceeded to update the patches using the "cached" parameter and
> > updated the corresponding comments to it in 0002.
>
> OK, I'm in favor of the name "cached" now, although I first agreed with
> Horiguchi-san in that it's better to use a name that represents the nature
> (accurate) of information rather than the implementation (cached). Having
> a second thought, since smgr is a component that manages relation files on
> storage (file system), lseek(SEEK_END) is the accurate value for smgr. The
> cached value holds a possibly stale size up to which the relation has
> extended.
>
>
> The patch looks almost good except for the minor ones:
Thank you for the review!
> (1)
> +extern BlockNumber smgrnblocks(SMgrRelation reln, ForkNumber
> forknum,
> + bool *accurate);
>
> It's still accurate here.
Already fixed in 0002.
> (2)
> + * This is only called in recovery when the block count of any
> fork is
> + * cached and the total number of to-be-invalidated blocks per
> relation
>
> count of any fork is
> -> counts of all forks are
Fixed in 0003/
> (3)
> In 0004, I thought you would add the invalidated block counts of all relations
> to determine if the optimization is done, as Horiguchi-san suggested. But I
> find the current patch okay too.
Yeah, I found my approach easier to implement. The new change in 0004 is that
when entering the optimized path we now call FindAndDropRelFileNodeBuffers()
instead of DropRelFileNodeBuffers().
I have attached all the updated patches.
I'd appreciate your feedback.
Regards,
Kirk Jamison
Attachment | Content-Type | Size |
---|---|---|
v31-0001-Prevent-invalidating-blocks-in-smgrextend-during.patch | application/octet-stream | 1.1 KB |
v31-0002-Add-bool-param-in-smgrnblocks-for-cached-blocks.patch | application/octet-stream | 9.5 KB |
v31-0003-Optimize-DropRelFileNodeBuffers-during-recovery.patch | application/octet-stream | 8.6 KB |
v31-0004-TRUNCATE-optimization.patch | application/octet-stream | 7.1 KB |
From | Date | Subject | |
---|---|---|---|
Next Message | tsunakawa.takay@fujitsu.com | 2020-11-12 04:13:35 | RE: [Patch] Optimize dropping of relation buffers using dlist |
Previous Message | Alexander Korotkov | 2020-11-12 03:48:17 | Re: Strange GiST logic leading to uninitialized memory access in pg_trgm gist code |