RE: [Patch] Optimize dropping of relation buffers using dlist - Mailing list pgsql-hackers

From k.jamison@fujitsu.com
Subject RE: [Patch] Optimize dropping of relation buffers using dlist
Date
Msg-id OSBPR01MB23418D2D93EBF7FEA9839923EFF80@OSBPR01MB2341.jpnprd01.prod.outlook.com
Whole thread Raw
In response to Re: [Patch] Optimize dropping of relation buffers using dlist  (Kyotaro Horiguchi <horikyota.ntt@gmail.com>)
Responses Re: [Patch] Optimize dropping of relation buffers using dlist
List pgsql-hackers
> From: Kyotaro Horiguchi <horikyota.ntt@gmail.com>
> Hello, Kirk. Thank you for the new version.

Hi, Horiguchi-san. Thank you for your very helpful feedback.
I'm updating the patches addressing those.

> +            if (!smgrexists(rels[i], j))
> +                continue;
> +
> +            /* Get the number of blocks for a relation's fork */
> +            blocks[i][numForks] = smgrnblocks(rels[i], j,
> NULL);
>
> If we see a fork which its size is not cached we must give up this optimization
> for all target relations.

I did not use the "cached" flag in DropRelFileNodesAllBuffers and use InRecovery
when deciding for optimization because of the following reasons:
XLogReadBufferExtended() calls smgrnblocks() to apply changes to relation page
contents. So in DropRelFileNodeBuffers(), XLogReadBufferExtended() is called
during VACUUM replay because VACUUM changes the page content.
OTOH, TRUNCATE doesn't change the relation content, it just truncates relation pages
without changing the page contents. So XLogReadBufferExtended() is not called, and
the "cached" flag will always return false. I tested with "cached" flags before, and this
always return false, at least in DropRelFileNodesAllBuffers. Due to this, we cannot use
the cached flag in DropRelFileNodesAllBuffers(). However, I think we can still rely on
smgrnblocks to get the file size as long as we're InRecovery. That cached nblocks is still
guaranteed to be the maximum in the shared buffer.
Thoughts?

Regards,
Kirk Jamison



pgsql-hackers by date:

Previous
From: Bharath Rupireddy
Date:
Subject: Re: [PATCH] postgres_fdw connection caching - cause remote sessions linger till the local session exit
Next
From: David Zhang
Date:
Subject: Re: Add table access method as an option to pgbench