From: | James Coleman <jtc331(at)gmail(dot)com> |
---|---|
To: | Andres Freund <andres(at)anarazel(dot)de> |
Cc: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: execExprInterp() questions / How to improve scalar array op expr eval? |
Date: | 2020-04-12 12:55:44 |
Message-ID: | CAAaqYe88Po5-Gya1aCZD7Y7RJAsFDTb1d68r200zG=tHo=v7Hw@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Sat, Apr 11, 2020 at 5:32 PM Andres Freund <andres(at)anarazel(dot)de> wrote:
>
> Hi,
>
> On 2020-04-11 15:53:11 -0400, James Coleman wrote:
> > On Sat, Apr 11, 2020 at 2:01 PM Andres Freund <andres(at)anarazel(dot)de> wrote:
> > > > - If not, is there a way in that framework to know if the array expr
> > > > has stayed the same through multiple evaluations of the expression
> > > > tree (i.e., so you could expand and sort it just once)?
> > >
> > > No.
> >
> > Ok. Seems like it'd be likely to be interesting (maybe in other places
> > too?) to know if:
> > - Something is actually a param that can change, and,
> > - When (perhaps by some kind of flag or counter) it has changed.
>
> We do have the param logic inside the executor, which does signal which
> params have changed. It's just independent of expression evaluation.
>
> I'm not convinced (or well, even doubtful) this is something we want to
> have at the expression evaluation level.
Perhaps I'll discover the reason as I internalize the code, but could
you expound a bit? Is that because you believe there's a better way to
optimize subexpressions that don't change? Or that it's likely to add
a lot of cost to non-optimized cases?
James
From | Date | Subject | |
---|---|---|---|
Next Message | Magnus Hagander | 2020-04-12 14:09:13 | Re: where should I stick that backup? |
Previous Message | Fabien COELHO | 2020-04-12 11:53:40 | Re: pg_ls_tmpdir to show directories and shared filesets (and pg_ls_*) |