On Tue, Jul 29, 2025 at 12:57 AM Tom Lane wrote:
> David Rowley writes:
> > For the record, I 100% agree that there will always be cases where
> > statistics are just unable to represent what is discovered at
> > run-time, so having some sort of ability to adapt at run-time seems
> > like a natur
On 29/7/2025 06:30, David Rowley wrote:
On Tue, 29 Jul 2025 at 16:01, Richard Guo wrote:
Another possible direction is to support runtime plan correction or
feedback loops. We've always followed a "plan-first, execute-next"
approach so far. But perhaps we could extend that by monitoring plan
David Rowley writes:
> For the record, I 100% agree that there will always be cases where
> statistics are just unable to represent what is discovered at
> run-time, so having some sort of ability to adapt at run-time seems
> like a natural progression on the evolutionary chain. I just don't
> kno
On Tue, 29 Jul 2025 at 16:01, Richard Guo wrote:
> Another possible direction is to support runtime plan correction or
> feedback loops. We've always followed a "plan-first, execute-next"
> approach so far. But perhaps we could extend that by monitoring plan
> execution and triggering re-optimiz
On Tue, Jul 29, 2025 at 6:30 AM David Rowley wrote:
> On the whole, I don't really see this as a flaw in the Memoize code.
> We've plenty of other cases in the planner that produce inferior plans
> due to lack of enough detail or accuracy of table statistics, so I'm
> not planning on rushing to lo
On Mon, 28 Jul 2025 at 20:13, Richard Guo wrote:
> create table t (a int, b int, c int);
> insert into t select i%3, i, i from generate_series(1,500)i;
> analyze t;
>
> explain (analyze, costs off, timing off)
> select * from t t1 join lateral
> (select t2.a, t2.b, t1.a x from t t2, t t3 offset
