>> Consider join of tables "a", "b" and "c". My understanding is that
>> make_join_rel() is called once with rel1={a} and rel2={b join c}, then with
>> rel1={a join b} and rel2={c}, etc. I wanted to say that each call should
>> produce the same set of unique keys.
>>
>> I need to check this
Antonin Houska writes:
>> Could you make the reason clearer for adding 'List *opfamily_lists;'
>> into UniqueKey? You said "This is needed to create ECs in the parent
>> query if the upper relation represents a subquery." but I didn't get the
>> it. Since we need to maintain the UniqueKey in
Antonin Houska wrote:
> Andy Fan wrote:
> > >
> > > * Combining the UKs
> > >
> > > IMO this is the most problematic part of the patch. You call
> > > populate_joinrel_uniquekeys() for the same join multiple times,
> >
> > Why do you think so? The below code is called in "make_join_rel"
>
Andy Fan wrote:
> > * I think that, before EC is considered suitable for an UK, its
> > ec_opfamilies
> > field needs to be checked. I try to do that in
> > find_ec_position_matching_expr(), see 0004.
>
> Could you make the reason clearer for adding 'List *opfamily_lists;'
> into
Hello Antonin,
Thanks for interesting with this topic!
> * I think that, before EC is considered suitable for an UK, its ec_opfamilies
> field needs to be checked. I try to do that in
> find_ec_position_matching_expr(), see 0004.
Could you make the reason clearer for adding 'List
Hello Antonin,
> zhihuifan1...@163.com wrote:
>
>> Here is the v3, ...
>
> I'm trying to enhance the join removal functionality (will post my patch in a
> separate thread soon) and I consider your patch very helpful in this
> area.
Thanks for these words. The point 2) and 3) is pretty
zhihuifan1...@163.com wrote:
> Here is the v3, ...
I'm trying to enhance the join removal functionality (will post my patch in a
separate thread soon) and I consider your patch very helpful in this
area.
Following is my review. Attached are also some fixes and one enhancement:
propagation of
zhihuifan1...@163.com writes:
Hi,
Here is the v3, the mainly changes is it maintains the UniqueKey on
joinrel level, which probabaly is the most important part of this
feature. It shows how the UnqiueKey on joinrel is generated and how it
is discarded due to non-interesting-uniquekey and also
jian he writes:
> On Fri, Oct 20, 2023 at 4:33 PM wrote:
>>
>>
>> > i did some simple tests using text data type.
>> >
>> > it works with the primary key, not with unique indexes.
>> > it does not work when the column is unique, not null.
>> >
>> > The following is my test.
>>
>> Can you
On Fri, Oct 20, 2023 at 4:33 PM wrote:
>
>
> > i did some simple tests using text data type.
> >
> > it works with the primary key, not with unique indexes.
> > it does not work when the column is unique, not null.
> >
> > The following is my test.
>
> Can you simplify your test case please? I
> i did some simple tests using text data type.
>
> it works with the primary key, not with unique indexes.
> it does not work when the column is unique, not null.
>
> The following is my test.
Can you simplify your test case please? I can't undertand what "doesn't
work" mean here and for which
On Tue, Oct 17, 2023 at 11:21 AM wrote:
>
>
> thanks for the really good suggestion. Here is the newer version:
>
--- a/src/backend/optimizer/path/meson.build
+++ b/src/backend/optimizer/path/meson.build
@@ -10,4 +10,5 @@ backend_sources += files(
'joinrels.c',
'pathkeys.c',
jian he writes:
Hi jian,
> hi.
> After `git am`, I still cannot build.
>
> ../../Desktop/pg_sources/main/postgres/src/backend/optimizer/path/uniquekey.c:125:45:
> error: variable ‘var’ set but not used
> [-Werror=unused-but-set-variable]
> 125 | Var
hi.
After `git am`, I still cannot build.
../../Desktop/pg_sources/main/postgres/src/backend/optimizer/path/uniquekey.c:125:45:
error: variable ‘var’ set but not used
[-Werror=unused-but-set-variable]
125 | Var*var;
|
14 matches
Mail list logo
