On Tue, May 13, 2025 at 10:51 PM Andres Freund wrote:
> This is failing on CI:
> https://cirrus-ci.com/github/postgresql-cfbot/postgresql/cf%2F5636
> https://api.cirrus-ci.com/v1/artifact/task/5411026402803712/testrun/build-32/testrun/regress/regress/regression.diffs
>
> diff -U3 /tmp/cirrus-ci-bu
Hi,
On 2025-04-10 19:36:14 +0900, Richard Guo wrote:
> On Wed, Apr 9, 2025 at 6:18 PM David Rowley wrote:
> > On Wed, 9 Apr 2025 at 18:48, Richard Guo wrote:
> > > Perhaps we could spend some planner cycles proving inner_unique for
> > > anti joins, so that Memoize nodes can be considered for th
On 4/9/25 08:48, Richard Guo wrote:
Perhaps we could spend some planner cycles proving inner_unique for
anti joins, so that Memoize nodes can be considered for them?
Thanks for working on it!
It is an example I have eagerly wanted to find.
So, no rush this feature now, I add it to the July commi
On Wed, Apr 9, 2025 at 6:18 PM David Rowley wrote:
> On Wed, 9 Apr 2025 at 18:48, Richard Guo wrote:
> > Perhaps we could spend some planner cycles proving inner_unique for
> > anti joins, so that Memoize nodes can be considered for them?
> Worth a try. It should be pretty easy to enable, as far
On Wed, 9 Apr 2025 at 18:48, Richard Guo wrote:
>
> On Thu, Mar 20, 2025 at 3:02 PM David Rowley wrote:
> > For making this work, I think the attached should be about the guts of
> > the code changes. I didn't look at the comments. Right now I can't
> > think of any reason why this can't be done,
On Thu, Mar 20, 2025 at 3:02 PM David Rowley wrote:
> For making this work, I think the attached should be about the guts of
> the code changes. I didn't look at the comments. Right now I can't
> think of any reason why this can't be done, but some experimentation
> might reveal some reason that i
On Thu, Mar 20, 2025 at 3:02 PM David Rowley wrote:
> For making this work, I think the attached should be about the guts of
> the code changes. I didn't look at the comments. Right now I can't
> think of any reason why this can't be done, but some experimentation
> might reveal some reason that i
On 20/3/2025 07:02, David Rowley wrote:
On Thu, 20 Mar 2025 at 06:16, Andrei Lepikhov wrote:
How can we be sure that semi or anti-join needs only one tuple? I think
it would be enough to control the absence of join clauses and filters in
the join. Unfortunately, we only have such a guarantee in
I realized that I uploaded my diff file with a small mistake - sorry
about that. I've corrected it with this message so your tests can pass
in the CI.
On 31.03.2025 05:33, Alena Rybakina wrote:
Hi!
On 21.03.2025 18:56, Andrei Lepikhov wrote:
On 20/3/2025 07:02, David Rowley wrote:
On Thu, 2
On 3/31/25 11:03, Richard Guo wrote:
On Thu, Mar 20, 2025 at 3:02 PM David Rowley wrote:
For making this work, I think the attached should be about the guts of
the code changes. I didn't look at the comments. Right now I can't
think of any reason why this can't be done, but some experimentation
On 4/1/25 09:18, Richard Guo wrote:
On Mon, Mar 31, 2025 at 7:33 PM Andrei Lepikhov wrote:
and I don't get the case. As I see, ANTI/SEMI join just transforms to
the regular join and it is still not the case. May you be more specific?
Upthread, you said that a qual contained in ppi_clauses wil
On Mon, Mar 31, 2025 at 7:33 PM Andrei Lepikhov wrote:
> and I don't get the case. As I see, ANTI/SEMI join just transforms to
> the regular join and it is still not the case. May you be more specific?
Upthread, you said that a qual contained in ppi_clauses will also be
included in extra->restric
On Mon, Mar 31, 2025 at 6:46 PM Andrei Lepikhov wrote:
> On 3/31/25 11:03, Richard Guo wrote:
> > I reviewed this patch and I have some concerns about the following
> > code:
> >
> > if (extra->inner_unique &&
> > (inner_path->param_info == NULL ||
> > bms_num_members(inner
On 3/31/25 12:18, Richard Guo wrote:
On Mon, Mar 31, 2025 at 6:46 PM Andrei Lepikhov wrote:
Nested Loop
-> Seq Scan on t t2
-> Nested Loop
-> Seq Scan on t t1
-> Subquery Scan on t3
Filter: ((t2.a = t3.a) AND (t1.b = t3.b))
-> Se
On Mon, Mar 31, 2025 at 6:39 PM David Rowley wrote:
> On Mon, 31 Mar 2025 at 22:03, Richard Guo wrote:
> > I reviewed this patch and I have some concerns about the following
> > code:
> >
> > if (extra->inner_unique &&
> > (inner_path->param_info == NULL ||
> > bms_num_member
On Mon, 31 Mar 2025 at 22:03, Richard Guo wrote:
> I reviewed this patch and I have some concerns about the following
> code:
>
> if (extra->inner_unique &&
> (inner_path->param_info == NULL ||
> bms_num_members(inner_path->param_info->ppi_serials) <
> list_length(ext
On 3/31/25 05:33, David Rowley wrote:
I can't say definitively that we won't find a reason in the future
that we should set inner_unique for SEMI/ANTI joins, so I don't follow
the need for the Assert.
Maybe you're seeing something that I'm not. What do you think will
break if both flags are true
On 31.03.2025 06:33, David Rowley wrote:
On Mon, 31 Mar 2025 at 16:21, Alena Rybakina wrote:
However, is it necessary to check that extra->inner_unique must be false for
SEMI/ANTI joins here, or am I missing something? It looks a little confusing at
this point.
If it is necessary, I don't se
On Mon, 31 Mar 2025 at 15:33, Alena Rybakina wrote:
> I believe it's worth asserting that both inner_unique and single_mode are not
> true at the same time — just as a safety check.
add_paths_to_joinrel() just chooses not to populate inner_unique for
SEMI and ANTI joins because, as of today's ma
On 31.03.2025 06:04, David Rowley wrote:
On Mon, 31 Mar 2025 at 15:33, Alena Rybakina wrote:
I believe it's worth asserting that both inner_unique and single_mode are not
true at the same time — just as a safety check.
add_paths_to_joinrel() just chooses not to populate inner_unique for
SEMI
On Mon, 31 Mar 2025 at 16:21, Alena Rybakina wrote:
> However, is it necessary to check that extra->inner_unique must be false for
> SEMI/ANTI joins here, or am I missing something? It looks a little confusing
> at this point.
If it is necessary, I don't see the reason for it. It was me that
wo
Hi!
On 21.03.2025 18:56, Andrei Lepikhov wrote:
On 20/3/2025 07:02, David Rowley wrote:
On Thu, 20 Mar 2025 at 06:16, Andrei Lepikhov wrote:
How can we be sure that semi or anti-join needs only one tuple? I think
it would be enough to control the absence of join clauses and
filters in
the j
On Thu, 20 Mar 2025 at 06:16, Andrei Lepikhov wrote:
> How can we be sure that semi or anti-join needs only one tuple? I think
> it would be enough to control the absence of join clauses and filters in
> the join. Unfortunately, we only have such a guarantee in the plan
> creation stage (maybe eve
On 6/3/2025 14:08, Andrei Lepikhov wrote:
Hi,
In case of NestLoop with parameterised inner semi-join for each outer
tuple requires only a single tuple from its inner relation to produce a
result. It seems that the same principle applies to an anti-join. This
approach could effectively allow t
Hi,
In case of NestLoop with parameterised inner semi-join for each outer
tuple requires only a single tuple from its inner relation to produce a
result. It seems that the same principle applies to an anti-join. This
approach could effectively allow the Memoize node to enhance the
performance
25 matches
Mail list logo
