On 2020-Aug-19, Amit Langote wrote:
Hello
> On Thu, Aug 6, 2020 at 4:25 PM kato-sho@fujitsu.com
> <kato-sho@fujitsu.com> wrote:
> > On Wednesday, August 5, 2020 9:43 AM I wrote:
> > > I'll report the result before the end of August .
> >
> > I test v2-0001-build-partdesc-memcxt.patch at 9a9db08ae4 and it is ok.
>
> Is this patch meant for HEAD or back-patching? I ask because v13 got this:
>
> commit 5b9312378e2f8fb35ef4584aea351c3319a10422
> Author: Tom Lane <tgl@sss.pgh.pa.us>
> Date: Wed Dec 25 14:43:13 2019 -0500
>
> Load relcache entries' partitioning data on-demand, not immediately.
>
> which prevents a partitioned table's PartitionDesc from being rebuilt
> repeatedly as would happen before this commit in Kato-san's case,
> because it moves RelationBuildPartitionDesc out of the relcache flush
> code path.
Hmm, so this is a problem only in v11 and v12? It seems that putting
the patch in master *only* is pointless. OTOH v11 had other severe
performance drawbacks with lots of partitions, so it might not be needed
there.
I admit I'm hesitant to carry code in only one or two stable branches
that exists nowhere else. But maybe the problem is serious enough in
those branches (that will still live for quite a few years) that we
should get it there.
OTOH it could be argued that the coding in master is not all that great
anyway (given the willingness for memory to be leaked) that it should
apply to all three branches.
--
Álvaro Herrera https://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services