On 7/1/24 16:17, Andrei Lepikhov wrote:
On 10/12/23 14:52, Andy Fan wrote:
Here the sublink can't be pulled up because of its reference to
the LHS of left join, the original logic is that no matter the 'b.t
in ..'
returns the true or false, the rows in LHS will be returned. If we
pull it up
On 10/12/23 14:52, Andy Fan wrote:
Here the sublink can't be pulled up because of its reference to
the LHS of left join, the original logic is that no matter the 'b.t in ..'
returns the true or false, the rows in LHS will be returned. If we
pull it up to LHS, some rows in LHS will be filtered
Hi Alexander,
> Hi!
>
>> If the changes of Alena are ok, can you merge the changes and post an
>> updated version so that CFBot can apply the patch and verify the
>> changes. As currently CFBot is trying to apply only Alena's changes
>> and failing with the following at [1]:
>
> I think this is
Hi!
> If the changes of Alena are ok, can you merge the changes and post an
> updated version so that CFBot can apply the patch and verify the
> changes. As currently CFBot is trying to apply only Alena's changes
> and failing with the following at [1]:
I think this is a very nice and pretty simp
On Fri, 13 Oct 2023 at 14:09, Alena Rybakina wrote:
>
> On 13.10.2023 10:04, Andy Fan wrote:
>>
>> It seems to me that the expressions "=" and "IN" are equivalent here due to
>> the fact that the aggregated subquery returns only one value, and the result
>> with the "IN" operation can be conside
On 13.10.2023 10:04, Andy Fan wrote:
It seems to me that the expressions "=" and "IN" are equivalent
here due to the fact that the aggregated subquery returns only one
value, and the result with the "IN" operation can be considered as
the intersection of elements on the left and
Hi Tom,
Would you like to have a look at this? The change is not big and the
optimization has also been asked for many times. The attached is the
v5 version and I also try my best to write a good commit message.
Here is the commit fest entry:
https://commitfest.postgresql.org/45/4268/
v5-000
>
> It seems to me that the expressions "=" and "IN" are equivalent here due
> to the fact that the aggregated subquery returns only one value, and the
> result with the "IN" operation can be considered as the intersection of
> elements on the left and right. In this query, we have some kind of set
On 12.10.2023 10:52, Andy Fan wrote:
Unfortunately, I found a request when sublink did not pull-up, as
in the
examples above. I couldn't quite figure out why.
I'm not sure what you mean with the "above", I guess it should be the
"below"?
Yes, you are right)
explain (anal
Hi Alena,
On Thu, Oct 12, 2023 at 5:01 AM Alena Rybakina
wrote:
> Hi!
>
> I reviewed your patch and it was interesting for me!
>
> Thank you for the explanation. It was really informative for me!
>
Thanks for your interest in this, and I am glad to know it is informative.
> Unfortunately, I fo
Hi!
I reviewed your patch and it was interesting for me!
Thank you for the explanation. It was really informative for me!
I think we need the restriction and that should be enough for this feature
. Given the query Richard provided before:
explain
select * from tenk1 A where exists
(select 1
Hi Tom:
Sorry for the delayed response! I think my knowledge has been refreshed
for this discussion.
> One thing I'm not at all clear about is whether we need to restrict
> the optimization so that it doesn't occur if the subquery contains
> outer references falling outside available_rels. I
Hi All:
Sorry for the delay. Once I saw Tom's reply on Nov 15, I tried his
suggestion about "whether we need to restrict the optimization so
that it doesn't occur if the subquery contains outer references
falling outside available_rels. " quickly, I'm sure such a restriction
can fix the bad
On Fri, 6 Jan 2023 at 11:46, vignesh C wrote:
>
> On Sun, 13 Nov 2022 at 04:15, Tom Lane wrote:
> >
> > Andy Fan writes:
> > > In the past we pull-up the ANY-sublink with 2 steps, the first step is to
> > > pull up the sublink as a subquery, and the next step is to pull up the
> > > subquery if
On Sun, 13 Nov 2022 at 04:15, Tom Lane wrote:
>
> Andy Fan writes:
> > In the past we pull-up the ANY-sublink with 2 steps, the first step is to
> > pull up the sublink as a subquery, and the next step is to pull up the
> > subquery if it is allowed. The benefits of this method are obvious,
> >
On Sun, Nov 13, 2022 at 6:45 AM Tom Lane wrote:
> Looking again at that contain_vars_of_level restriction, I think the
> reason for it was just to avoid making a FROM subquery that has outer
> references, and the reason we needed to avoid that was merely that we
> didn't have LATERAL at the time.
Andy Fan writes:
> In the past we pull-up the ANY-sublink with 2 steps, the first step is to
> pull up the sublink as a subquery, and the next step is to pull up the
> subquery if it is allowed. The benefits of this method are obvious,
> pulling up the subquery has more requirements, even if we c
Hi Andrey:
> > In this patch we distinguish the above case and try to pull-up it within
> > one step if it is helpful, It looks to me that what we need to do is just
> > transform it to EXIST-SUBLINK.
> Maybe code [1] would be useful for your purposes/tests.
>
Looks like we are resolving the sam
On 2/11/2022 09:02, Andy Fan wrote:
In the past we pull-up the ANY-sublink with 2 steps, the first step is to
pull up the sublink as a subquery, and the next step is to pull up the
subquery if it is allowed. The benefits of this method are obvious,
pulling up the subquery has more requirements,
In the past we pull-up the ANY-sublink with 2 steps, the first step is to
pull up the sublink as a subquery, and the next step is to pull up the
subquery if it is allowed. The benefits of this method are obvious,
pulling up the subquery has more requirements, even if we can just finish
the first s
20 matches
Mail list logo
