Re: Trying to pull up EXPR SubLinks

From: Andy Fan <zhihui(dot)fan1213(at)gmail(dot)com>
To: David Rowley <dgrowleyml(at)gmail(dot)com>
Cc: Richard Guo <guofenglinux(at)gmail(dot)com>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Trying to pull up EXPR SubLinks
Date: 2020-04-24 09:54:03
Message-ID: CAKU4AWo4HCjzzzY077=5UDUM75gAh4Q6hxjhbKc13zoiRKxWMA@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Fri, Apr 24, 2020 at 5:24 PM David Rowley <dgrowleyml(at)gmail(dot)com> wrote:

> On Fri, 24 Apr 2020 at 15:26, Andy Fan <zhihui(dot)fan1213(at)gmail(dot)com> wrote:
> >
> > Actually I have a different opinion to handle this issue, to execute the
> > a > (select avg(a) from tinner where x = touer.x); The drawback of
> current
> > path is because it may calculates the same touer.x value multi-times. So
> > if we cache the values we have calculated before, we can avoid the cost.
> > Material path may be the one we can reference but it assumes all the
> tuples
> > in the tuplestore matches the input params, which is not the fact here.
> >
> > But what if the input params doesn't change? If so we can use Material
> path
> > to optimize this case. But since we don't know if the if the input
> params changed
> > or not during plan time, we just add the path (let's assume we can add
> it with some
> > rules or cost calculation). If the input params is not changed, we use
> the cached
> > values, if the input params changed, we can ReScan the Material node.
> To optimize
> > the the cache invalidation frequent issue like (1, 2, 1, 2, 1, 2) case,
> we may consider
> > a sort path to change the input values to (1, 1, 1, 2, 2, 2). But
> overall it is a big effort.
>
> This does not seem quite right to me. What you need is some sort of
> parameterized materialize. Materialize just reads its subnode and
> stores the entire thing input and reuses it any time that it
> rescanned.
>
> You likely need something more like what is mentioned in [1]. There's
> also a bunch of code from Heikki in the initial email in that thread.
> Heikki put it in nodeSubplan.c. I think it should be a node of its
> own.
>
>
Glad to see your feedback, David:). Actually I thought about this idea
some
time ago, but since we have to implement a new path and handle
the cached data is too huge case, I gave it up later. When I am working
on some other stuff, I found Material path with some chgParam change may
get a no harmful improvement with less effort, based on we know how to
add the material path and we can always get a correct result.

I will check the link you provide when I get time, It's a nice feature and
it will be a
good place to continue working on that feature.

Best Regards
Andy Fan

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Jehan-Guillaume de Rorthais 2020-04-24 10:15:26 Re: +(pg_lsn, int8) and -(pg_lsn, int8) operators
Previous Message David Rowley 2020-04-24 09:24:03 Re: Trying to pull up EXPR SubLinks