MIME-Version: 1.0
References: <CAExHW5tUcVsBkq9qT=L5vYz4e-cwQNw=KAGJrtSyzOp3F=XacA@mail.gmail.com>
 <CAApHDvoDc4QwxMH4h_WRjJO4NK47L_gafv0oTpyjAkXKyXFz_A@mail.gmail.com>
 <CAExHW5u-X+7xj2udyXSxqPhqyLDz99o_Ev6YoPViZX5tT0Uquw@mail.gmail.com>
 <CAApHDvrc4UoP=E+zzVdQRgC0gJ37+W_zw=3wjnLkXJhvToZ50A@mail.gmail.com>
 <CAExHW5uDkMQL8SicV3_=AYcsWwMTNR8GzJo310J7sv7TMLoL6Q@mail.gmail.com>
 <CAExHW5s1ZX3HF2q9Tcmo9wxkfPp6pEdmjSySP1Whc=M5__mXrQ@mail.gmail.com>
 <CAExHW5uAdVev9CQYrdZ7w0xucqp2mYHPzcCx6EevegZVVgDbLQ@mail.gmail.com>
 <c11abcfa-cdbf-4883-adbd-c09c6bc74b0d@postgrespro.ru> <CAExHW5vqfg8J-Oe4AOaUnBLz4rWhbJGDKFJHBDDEQ907Om53yg@mail.gmail.com>
 <182fbad0-f3f6-4692-8fc4-778378e1db01@postgrespro.ru> <CAExHW5s_y_VxHcGZ1XX5_J5Yf34DWHU=Czj6BRf23Qx3LhE6jg@mail.gmail.com>
 <bd68c396-5e17-4254-a2c3-992ab8e912cc@postgrespro.ru>
In-Reply-To: <bd68c396-5e17-4254-a2c3-992ab8e912cc@postgrespro.ru>
From: Ashutosh Bapat <ashutosh.bapat.oss@gmail.com>
Date: Tue, 20 Feb 2024 10:38:31 +0530
Message-ID: <CAExHW5tn25KxL92FF5R66phhfeUCV0AeFEZ95KCst+Fm5nm1Rg@mail.gmail.com>
Subject: Re: Memory consumed by paths during partitionwise join planning
To: Andrei Lepikhov <a.lepikhov@postgrespro.ru>
Cc: David Rowley <dgrowleyml@gmail.com>, pgsql-hackers <pgsql-hackers@postgresql.org>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Archived-At: <https://www.postgresql.org/message-id/CAExHW5tn25KxL92FF5R66phhfeUCV0AeFEZ95KCst%2BFm5nm1Rg%40mail.gmail.com>
Precedence: bulk

On Tue, Feb 20, 2024 at 8:19=E2=80=AFAM Andrei Lepikhov
<a.lepikhov@postgrespro.ru> wrote:
>
> On 19/2/2024 19:25, Ashutosh Bapat wrote:
> > On Fri, Feb 16, 2024 at 8:42=E2=80=AFAM Andrei Lepikhov
> > <a.lepikhov@postgrespro.ru> wrote:
> >> Live example: right now, I am working on the code like MSSQL has - a
> >> combination of NestLoop and HashJoin paths and switching between them =
in
> >> real-time. It requires both paths in the path list at the moment when
> >> extensions are coming. Even if one of them isn't referenced from the
> >> upper pathlist, it may still be helpful for the extension.
> >
> > There is no guarantee that every path presented to add_path will be
> > preserved. Suboptimal paths are freed as and when add_path discovers
> > that they are suboptimal. So I don't think an extension can rely on
> > existence of a path. But having a refcount makes it easy to preserve
> > the required paths by referencing them.
> I don't insist, just provide my use case. It would be ideal if you would
> provide some external routines for extensions that allow for sticking
> the path in pathlist even when it has terrible cost estimation.

With refcounts you can reference it and store it somewhere other than
pathlist. The path won't be lost until it is dereferrenced.
RelOptInfo::Pathlist is for optimal paths.

> >
> >>
> >>
> > IIUC, you are suggesting that instead of planning each
> > partition/partitionwise join, we only create paths with the strategies
> > which were found to be optimal with previous partitions. That's a good
> > heuristic but it won't work if partition properties - statistics,
> > indexes etc. differ between groups of partitions.
> Sure, but the "Symmetry" strategy assumes that on the scope of a
> thousand partitions, especially with parallel append involved, it
> doesn't cause sensible performance degradation if we find a bit
> suboptimal path in a small subset of partitions. Does it make sense?
> As I see, when people use 10-100 partitions for the table, they usually
> strive to keep indexes symmetrical for all partitions.
>

I agree that we need something like that. In order to do that, we need
machinery to prove that all partitions have similar properties. Once
that is proved, we can skip creating paths for similar partitions. But
that's out of scope of this work and complements it.

--=20
Best Wishes,
Ashutosh Bapat