On Fri, Apr 24, 2020 at 5:24 PM David Rowley wrote:
> On Fri, 24 Apr 2020 at 15:26, Andy Fan 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 calcu
On Fri, 24 Apr 2020 at 15:26, Andy Fan 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 val
On Fri, Apr 24, 2020 at 2:42 PM Andy Fan wrote:
>>
>>
>> > 3. I added the material path in a very hacked way, the if check just to
>> > make
>> > sure it take effect on my test statement only. If you want to test this
>> > patch locally,
>> > you need to change the oid for your case.
>> >
>>
>
>
> > 3. I added the material path in a very hacked way, the if check just
> to make
> > sure it take effect on my test statement only. If you want to test this
> patch locally,
> > you need to change the oid for your case.
> >
> > + if (linitial_node(RangeTblEntry, root->parse->rtable)-
On Fri, Apr 24, 2020 at 8:56 AM Andy Fan 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 v
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.
Mat
On Fri, Feb 28, 2020 at 11:35 PM Tom Lane wrote:
> Richard Guo writes:
> > On Fri, Feb 28, 2020 at 3:02 PM Andy Fan
> wrote:
> >> Glad to see this. I think the hard part is this transform is not
> *always*
> >> good. for example foo.a only has 1 rows, but bar has a lot of rows, if
> >> so th
Richard Guo writes:
> On Fri, Feb 28, 2020 at 3:02 PM Andy Fan wrote:
>> Glad to see this. I think the hard part is this transform is not *always*
>> good. for example foo.a only has 1 rows, but bar has a lot of rows, if
>> so the original would be the better one.
> Yes exactly. TBH I'm not s
On Fri, Feb 28, 2020 at 3:02 PM Andy Fan wrote:
>
>
> On Fri, Feb 28, 2020 at 2:35 PM Richard Guo
> wrote:
>
>> Hi All,
>>
>> Currently we will not consider EXPR_SUBLINK when pulling up sublinks and
>> this would cause performance issues for some queries with the form of:
>> 'a > (SELECT agg(b)
On Fri, Feb 28, 2020 at 2:35 PM Richard Guo wrote:
> Hi All,
>
> Currently we will not consider EXPR_SUBLINK when pulling up sublinks and
> this would cause performance issues for some queries with the form of:
> 'a > (SELECT agg(b) from ...)' as described in [1].
>
> So here is a patch as an att
Hi All,
Currently we will not consider EXPR_SUBLINK when pulling up sublinks and
this would cause performance issues for some queries with the form of:
'a > (SELECT agg(b) from ...)' as described in [1].
So here is a patch as an attempt to pull up EXPR SubLinks. The idea,
which is based on Greenp
11 matches
Mail list logo
