[PATCH] Keeps tracking the uniqueness with UniqueKey

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
8 messages Options
Reply | Threaded
Open this post in threaded view
|

[PATCH] Keeps tracking the uniqueness with UniqueKey

Andy Fan
Greetings.

This thread is a follow-up thread for [1], where I submit a patch for erasing the
distinct node if we have known the data is unique for sure.  But since the 
implementation has changed a lot from the beginning and they are not very 
related, so I start this new thread to discuss the new strategy to save the time 
of reviewers.

As I said above, my original intention is just used to erase the distinct clause,  
then Tom Lane suggested function query_is_distinct_for,  I found the uniqueness 
can be used for costing,  remove_useless_join, reduce_unqiue_semijoins.  
David suggested to maintain the uniqueness from bottom to top, like join 
& subqueries, group-by, distinct, union and so on(we call it as UniqueKey).  
Ideally the uniqueness will be be lost in any case. This current implementation
follows the David's suggestion and also thanks Ashutosh who reminded me 
the cost should be ok while I had concerns of this at the beginning.

A new field named uniquekeys was added in RelOptInfo struct, which is a
list of UniqueKey struct.  

typedef struct UniqueKey
{
    NodeTag     type;
    List       *exprs;
    List       *positions;
    bool       grantee;
} UniqueKey;

exprs is a list of exprs which is unique if we don't care about the null vaues on 
current RelOptInfo.

positions is a list of the sequence no. of the exprs in the current RelOptInfo, 
which is used for SubQuery. like

create table t1 (a int primary key, b int);
create table t2 (a int primary key, b int);
select .. from t1,  (select b from t2 group by t2) t2 ..;

The UniqueKey for the subquery will be Var(varno=1, varattno=2),  but for the 
top query, the UniqueKey of t2 should be Var(varno=2, varattrno=1),  the 1 here 
need to be calculated by UnqiueKey->positions.

grantee field is introduced mainly for remove_useless_join & reduce_unique_semijions. 
Take the above case for example:

-- b is nullable.  so select b from t2 still can result in duplicated rows.
create unique index t2_uk_b on t2(b);  

-- the left join still can be removed since t2.b is a unique index and the nullable 
doesn't matter here.
select t1.* from t1 left join t2 on (t1.b = t2.b);  

so t2.b will still be an UniqueKey for t2, just that the grantee = false.

A branch of functions like populate_xxx_unqiuekeys for manipulating uniquekeys 
for a lot of cases, xxx maybe baserel, joinrel, paritioned table, unionrel, groupbyrel, 
distincrel and so on.  partitioned table has some not obviously troubles due to 
users can create index on the childrel directly and differently.  You can check 
the comments of the code for details.


When maintaining the uniquekeys of joinrel,  we have a rule that if both rels have 
UniqueKeys,  then any combination from the 2 sides is a unqiquekey of the joinrel. 
I used two algorithms to keep the length of the UniqueKeys short.  One is we only 
add useful UniqueKey to the RelOptInfo.uniquekeys.  If the expr isn't shown in 
rel->reltargets->exprs, it will not be used for others, so we can ignore it safely. 
The another one is if column sets A is unqiuekey already,  any superset of A 
will no need to be added as an UnqiueKey. 


The overall cost of the maintaining unqiuekeys should be ok.  If you check the code,
you may find there are many 2 or 3 levels foreach, but most of them are started with 
unique index, and I used UnqiueKeyContext and SubqueryUnqiueKeyContext in joinrel 
and subquery case to avoid too many loops.

Now I have used the UnqiueKey to erase the unnecessary distinct/group by, and also changed
the rel_is_distinct_for to use UnqiueKeys.  so we can handle more cases.

create table m1 (a int primary key,  b int, c int);
create table m2 (a int primary key,  b int, c int);
create table m3 (a int primary key,  b int, c int);

Wit the current patch, we can get:
task3=# explain select  t1.a from m3 t1 left join  (select m1.a from m1, m2 where m1.b = m2.a limit 1) t2 on (t1.a = t2.a);
                       QUERY PLAN
---------------------------------------------------------
 Seq Scan on m3 t1  (cost=0.00..32.60 rows=2260 width=4)


Before the patch, we will get:
postgres=# explain select  t1.a from m3 t1 left join  (select m1.a from m1, m2 where m1.b = m2.a limit 1) t2 on (t1.a = t2.a)
postgres-# ;
                                          QUERY PLAN
-----------------------------------------------------------------------------------------------
 Hash Left Join  (cost=0.39..41.47 rows=2260 width=4)
   Hash Cond: (t1.a = m1.a)
   ->  Seq Scan on m3 t1  (cost=0.00..32.60 rows=2260 width=4)
   ->  Hash  (cost=0.37..0.37 rows=1 width=4)
         ->  Limit  (cost=0.15..0.36 rows=1 width=4)
               ->  Nested Loop  (cost=0.15..470.41 rows=2260 width=4)
                     ->  Seq Scan on m1  (cost=0.00..32.60 rows=2260 width=8)
                     ->  Index Only Scan using m2_pkey on m2  (cost=0.15..0.19 rows=1 width=4)
                           Index Cond: (a = m1.b)


The "limit 1" here is just want to avoid the pull_up_subquery to pull up the subquery,  
I think we may still have opportunities to improve this further if we check if we can 
remove a join *just before we join 2 relations*.  we may have the similar situation 
for reduce_unique_semijions joins.  After the changes has been done, we can remove 
the "limit 1" here to show the diffidence.  I didn't include this change in current patch 
since I think the effort may be not small and I want to keep this patch simple.

Some known issues needs attentions:
1. I didn't check the collation at the whole stage, one reason is the relation_has_unique_index_for
 doesn't check it as well.  The other reason if a in collation A is unique, and then A in collation B is 
unique as well,  we can ignore it. [2]
2. Current test case contrib/postgres_fdw/sql/postgres_fdw.sql is still failed.  I am not sure if 
the bug is in my patch or not.

Kindly waiting for your feedback,  Thanks you!




Best regards
Andy Fan

v1-0001-Maintain-the-uniqueness-of-a-Query-from-bottom-to.patch (114K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: [PATCH] Keeps tracking the uniqueness with UniqueKey

Andy Fan


On Mon, Mar 23, 2020 at 6:21 PM Andy Fan <[hidden email]> wrote:
Greetings.

This thread is a follow-up thread for [1], where I submit a patch for erasing the
distinct node if we have known the data is unique for sure.  But since the 
implementation has changed a lot from the beginning and they are not very 
related, so I start this new thread to discuss the new strategy to save the time 
of reviewers.

As I said above, my original intention is just used to erase the distinct clause,  
then Tom Lane suggested function query_is_distinct_for,  I found the uniqueness 
can be used for costing,  remove_useless_join, reduce_unqiue_semijoins.  
David suggested to maintain the uniqueness from bottom to top, like join 
& subqueries, group-by, distinct, union and so on(we call it as UniqueKey).  
Ideally the uniqueness will be be lost in any case. This current implementation
follows the David's suggestion and also thanks Ashutosh who reminded me 
the cost should be ok while I had concerns of this at the beginning.

A new field named uniquekeys was added in RelOptInfo struct, which is a
list of UniqueKey struct.  

typedef struct UniqueKey
{
    NodeTag     type;
    List       *exprs;
    List       *positions;
    bool       grantee;
} UniqueKey;

exprs is a list of exprs which is unique if we don't care about the null vaues on 
current RelOptInfo.

positions is a list of the sequence no. of the exprs in the current RelOptInfo, 
which is used for SubQuery. like

create table t1 (a int primary key, b int);
create table t2 (a int primary key, b int);
select .. from t1,  (select b from t2 group by t2) t2 ..;

The UniqueKey for the subquery will be Var(varno=1, varattno=2),  but for the 
top query, the UniqueKey of t2 should be Var(varno=2, varattrno=1),  the 1 here 
need to be calculated by UnqiueKey->positions.

grantee field is introduced mainly for remove_useless_join & reduce_unique_semijions. 
Take the above case for example:

-- b is nullable.  so select b from t2 still can result in duplicated rows.
create unique index t2_uk_b on t2(b);  

-- the left join still can be removed since t2.b is a unique index and the nullable 
doesn't matter here.
select t1.* from t1 left join t2 on (t1.b = t2.b);  

so t2.b will still be an UniqueKey for t2, just that the grantee = false.

A branch of functions like populate_xxx_unqiuekeys for manipulating uniquekeys 
for a lot of cases, xxx maybe baserel, joinrel, paritioned table, unionrel, groupbyrel, 
distincrel and so on.  partitioned table has some not obviously troubles due to 
users can create index on the childrel directly and differently.  You can check 
the comments of the code for details.


When maintaining the uniquekeys of joinrel,  we have a rule that if both rels have 
UniqueKeys,  then any combination from the 2 sides is a unqiquekey of the joinrel. 
I used two algorithms to keep the length of the UniqueKeys short.  One is we only 
add useful UniqueKey to the RelOptInfo.uniquekeys.  If the expr isn't shown in 
rel->reltargets->exprs, it will not be used for others, so we can ignore it safely. 
The another one is if column sets A is unqiuekey already,  any superset of A 
will no need to be added as an UnqiueKey. 


The overall cost of the maintaining unqiuekeys should be ok.  If you check the code,
you may find there are many 2 or 3 levels foreach, but most of them are started with 
unique index, and I used UnqiueKeyContext and SubqueryUnqiueKeyContext in joinrel 
and subquery case to avoid too many loops.

Now I have used the UnqiueKey to erase the unnecessary distinct/group by, and also changed
the rel_is_distinct_for to use UnqiueKeys.  so we can handle more cases.

create table m1 (a int primary key,  b int, c int);
create table m2 (a int primary key,  b int, c int);
create table m3 (a int primary key,  b int, c int);

Wit the current patch, we can get:
task3=# explain select  t1.a from m3 t1 left join  (select m1.a from m1, m2 where m1.b = m2.a limit 1) t2 on (t1.a = t2.a);
                       QUERY PLAN
---------------------------------------------------------
 Seq Scan on m3 t1  (cost=0.00..32.60 rows=2260 width=4)


Before the patch, we will get:
postgres=# explain select  t1.a from m3 t1 left join  (select m1.a from m1, m2 where m1.b = m2.a limit 1) t2 on (t1.a = t2.a)
postgres-# ;
                                          QUERY PLAN
-----------------------------------------------------------------------------------------------
 Hash Left Join  (cost=0.39..41.47 rows=2260 width=4)
   Hash Cond: (t1.a = m1.a)
   ->  Seq Scan on m3 t1  (cost=0.00..32.60 rows=2260 width=4)
   ->  Hash  (cost=0.37..0.37 rows=1 width=4)
         ->  Limit  (cost=0.15..0.36 rows=1 width=4)
               ->  Nested Loop  (cost=0.15..470.41 rows=2260 width=4)
                     ->  Seq Scan on m1  (cost=0.00..32.60 rows=2260 width=8)
                     ->  Index Only Scan using m2_pkey on m2  (cost=0.15..0.19 rows=1 width=4)
                           Index Cond: (a = m1.b)


The "limit 1" here is just want to avoid the pull_up_subquery to pull up the subquery,  
I think we may still have opportunities to improve this further if we check if we can 
remove a join *just before we join 2 relations*.  we may have the similar situation 
for reduce_unique_semijions joins.  After the changes has been done, we can remove 
the "limit 1" here to show the diffidence.  I didn't include this change in current patch 
since I think the effort may be not small and I want to keep this patch simple.

Some known issues needs attentions:
1. I didn't check the collation at the whole stage, one reason is the relation_has_unique_index_for
 doesn't check it as well.  The other reason if a in collation A is unique, and then A in collation B is 
unique as well,  we can ignore it. [2]
2. Current test case contrib/postgres_fdw/sql/postgres_fdw.sql is still failed.  I am not sure if 
the bug is in my patch or not.

Kindly waiting for your feedback,  Thanks you!



Just update the patch which do some test case changes.
1.    add "ANALYZE" command before running the explain.
2.    order by with an explicit collate settings.  
3.    As for the postgres_fdw.sql,  I just copied the results.out to expected.out,  
that's should be correct based on the result.  However I added my comment
around that. 

Now suppose the cbfot should pass this time. 

Best Regards.
Andy Fan

  
 

v2-0001-Maintain-the-uniqueness-of-a-Query-from-bottom-to.patch (121K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: [PATCH] Keeps tracking the uniqueness with UniqueKey

Andy Fan
Because I replied the old thread,  cfbot run a test based on the old patch
on that thread.  I have detached the old thread from commitfest.   Reply this 
email again to wake up Mr. cfbot with the right information.  

v2-0001-Maintain-the-uniqueness-of-a-Query-from-bottom-to.patch (121K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: [PATCH] Keeps tracking the uniqueness with UniqueKey

Andy Fan
In reply to this post by Andy Fan

Just update the patch which do some test case changes.
1.    add "ANALYZE" command before running the explain.
2.    order by with an explicit collate settings.  

Thanks  Rushabh for pointing this out, or else I'd spend much more time to figure
out why I get a different order on Windows. 

3.    As for the postgres_fdw.sql,  I just copied the results.out to expected.out,  
that's should be correct based on the result.  However I added my comment
around that. 

The issue doesn't exist at all.  The confusion was introduced by a misunderstanding
of the test case (I treated count (xx)  filter (xxx) as a window function rather than an aggration
function). so just fixed the it cleanly.

Some other changes made in the new patch:
1.   Fixed bug for UniqueKey calculation for OUTER join.
2.   Fixed some typo error in comments.
3.   Renamed the field "grantee" as "guarantee".

Best Regards
Andy Fan
  

v3-0001-Maintain-UniqueKey-at-each-RelOptInfo-this-inform.patch (120K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: [PATCH] Keeps tracking the uniqueness with UniqueKey

David Rowley
On Sun, 29 Mar 2020 at 20:50, Andy Fan <[hidden email]> wrote:
> Some other changes made in the new patch:
> 1.   Fixed bug for UniqueKey calculation for OUTER join.
> 2.   Fixed some typo error in comments.
> 3.   Renamed the field "grantee" as "guarantee".

I've had a look over this patch. Thank for you doing further work on it.

I've noted down the following during my read of the code:

1. There seem to be some cases where joins are no longer being
detected as unique. This is evident in postgres_fdw.out. We shouldn't
be regressing any of these cases.

2. The following change does not seem like it should be part of this
patch.  I understand you perhaps have done as you think it will
improve the performance of checking if an expression is in a list of
expressions.

- COMPARE_SCALAR_FIELD(varno);
+ /* Compare varattno first since it has higher selectivity than varno */
  COMPARE_SCALAR_FIELD(varattno);
+ COMPARE_SCALAR_FIELD(varno);

If you think that is true, then please do it as a separate effort and
provide benchmarks with your findings.

3. list_all_members_in. I think this would be better named as
list_is_subset. Please follow the lead of bms_is_subset().
Additionally, you should Assert that IsPointerList is true as there's
nothing else to indicate that it can't be used for an int or Oid list.

4. guarantee is not a very good name for the field in UniqueKey.
Maybe something like is_not_null?

5. I think you should be performing a bms_del_member during join
removal rather than removing this Assert()

- Assert(bms_equal(rel->relids, root->all_baserels));

FWIW, it's far from perfect that you've needed to delay the left join
removal, but I do understand why you've done it. It's also far from
perfect that you're including removed relations in the
total_table_pages calculation. c6e4133fae1 took some measures to
improve this calculation and this is making it worse again.

6. Can you explain why you moved the populate_baserel_uniquekeys()
call out of set_plain_rel_size()?

7. I don't think the removal of rel_supports_distinctness() is
warranted.  Is it not ok to check if the relation has any uniquekeys?
It's possible, particularly in join_is_removable that this can save
quite a large amount of effort.

8. Your spelling of unique is incorrect in many places:

src/backend/nodes/makefuncs.c: * makeUnqiueKey
src/backend/optimizer/path/uniquekeys.c:static List
*initililze_unqiuecontext_for_joinrel(RelOptInfo *joinrel,
src/backend/optimizer/path/uniquekeys.c: * check if combination of
unqiuekeys from both side is still useful for us,
src/backend/optimizer/path/uniquekeys.c:        outerrel_uniquekey_ctx
= initililze_unqiuecontext_for_joinrel(joinrel, outerrel);
src/backend/optimizer/path/uniquekeys.c:        innerrel_uniquekey_ctx
= initililze_unqiuecontext_for_joinrel(joinrel, innerrel);
src/backend/optimizer/path/uniquekeys.c: * we need to convert the
UnqiueKey from sub_final_rel to currel via the positions info in
src/backend/optimizer/path/uniquekeys.c:                ctx->pos =
pos; /* the position in current targetlist,  will be used to set
UnqiueKey */
src/backend/optimizer/path/uniquekeys.c: * Check if Unqiue key of the
innerrel is valid after join. innerrel's UniqueKey
src/backend/optimizer/path/uniquekeys.c: * initililze_unqiuecontext_for_joinrel
src/backend/optimizer/path/uniquekeys.c: * all the unqiuekeys which
are not possible to use later
src/backend/optimizer/path/uniquekeys.c:initililze_unqiuecontext_for_joinrel(RelOptInfo
*joinrel,  RelOptInfo *inputrel)
src/backend/optimizer/plan/analyzejoins.c:                      /*
This UnqiueKey is what we want */
src/backend/optimizer/plan/planner.c:   /* If we the result if unqiue
already, we just return the input_rel directly */
src/include/nodes/pathnodes.h: * exprs is a list of exprs which is
unqiue on current RelOptInfo.
src/test/regress/expected/join.out:-- XXXX: since b.id is unqiue now
so the group by cluase is erased, so
src/test/regress/expected/select_distinct.out:-- create unqiue index on dist_p
src/test/regress/expected/select_distinct.out:-- we also support
create unqiue index on each child tables
src/test/regress/sql/join.sql:-- XXXX: since b.id is unqiue now so the
group by cluase is erased, so
src/test/regress/sql/select_distinct.sql:-- create unqiue index on dist_p
src/test/regress/sql/select_distinct.sql:-- we also support create
unqiue index on each child tables

9. A few things wrong with the following fragment:

/* set the not null info now */
ListCell *lc;
foreach(lc, find_nonnullable_vars(qual))
{
Var *var = lfirst_node(Var, lc);
RelOptInfo *rel = root->simple_rel_array[var->varno];
if (var->varattno > InvalidAttrNumber)
rel->not_null_cols = bms_add_member(rel->not_null_cols, var->varattno);
}

a. including a function call in the foreach macro is not a practise
that we really follow. It's true that the macro now assigns the 2nd
param to a variable. Previous to 1cff1b95ab6 this was not the case and
it's likely best not to leave any bad examples around that code which
might get backported might follow.
b. We generally subtract InvalidAttrNumber from varattno when
including in a Bitmapset.
c. not_null_cols is not well named. I think notnullattrs
d. not_null_cols should not be a Relids type, it should be Bitmapset.

10. add_uniquekey_for_onerow() seems pretty wasteful.  Is there really
a need to add each item in the rel's targetlist to the uniquekey list?
What if we just add an empty list to the unique keys, that way if we
need to test if some expr is a superset of any uniquekey, then we'll
see it is as any set is a superset of an empty set.  Likely the empty
set of uniquekeys should be the only one in the rel's uniquekey list.

11. In create_distinct_paths() the code is now calling
get_sortgrouplist_exprs() multiple times with the same input. I think
it would be better to just call it once and set the result in a local
variable.

12. The comment in the code below is not true. The List contains
Lists, of which contain UniqueKeys

List    *uniquekeys; /* List of UniqueKey */

13. I'm having trouble parsing the final sentence in:

+ * can only guarantee the uniqueness without considering the null values. This
+ * field is necessary for remove_useless_join & reduce_unique_semijions since
+ * these cases don't care about the null values.

Why is the field which stores the nullability of the key required for
code that does not care about the nullability of the key?

Also please check your spelling of the word "join"

14. In the following fragment, instead of using i+1, please assign the
FormData_pg_attribute to a variable named attr and use attr->attnum.
Also, please see what I mentioned above about subtracting
InvalidAttrNumber

+ rel->not_null_cols = bms_add_member(rel->not_null_cols, i+1);

15. The tests you've changed the expected outcome of in join.out
should be updated so that the GROUP BY and DISTINCT clause is not
removed. This will allow the test to continue testing what it was
intended to test. You can do this by changing the columns in the GROUP
BY clause so that the new code does not find uniquekeys for those
columns.

16. The tests in aggregates.out are in a similar situation. There are
various tests trying to ensure that remove_useless_groupby_columns()
does what it's meant to do. You can modify these tests to add a join
which is non-unique to effectively duplicate the PK column.

17. In your select_distinct tests, can you move away from naming the
tables starting with select_distinct?  It makes reading queries pretty
hard.

e.g. explain (costs off) select distinct uk1, uk2 from
select_distinct_a where uk2 is not null;

When I first glanced that, I failed to see the underscores and the
query looked invalid.

18. Check the spelling if "erased". You have it spelt as "ereased" in
a couple of locations.

19. Please pay attention to the capitalisation of SQL keywords in the
test files you've modified. I understand we're very inconsistent in
this department in general, but we do at least try not to mix
capitalisation within the same file.  Basically, please upper case the
keywords in select_distinct.sql

20. In addition to the above, please try to wrap long SQL lines so
they're below 80 chars.

I'll review the patch in more detail once the above points have been addressed.

David


Reply | Threaded
Open this post in threaded view
|

Re: [PATCH] Keeps tracking the uniqueness with UniqueKey

Tom Lane-2
[ not a review, just some drive-by comments on David's comments ]

David Rowley <[hidden email]> writes:
> 2. The following change does not seem like it should be part of this
> patch.  I understand you perhaps have done as you think it will
> improve the performance of checking if an expression is in a list of
> expressions.

> - COMPARE_SCALAR_FIELD(varno);
> + /* Compare varattno first since it has higher selectivity than varno */
>   COMPARE_SCALAR_FIELD(varattno);
> + COMPARE_SCALAR_FIELD(varno);

> If you think that is true, then please do it as a separate effort and
> provide benchmarks with your findings.

By and large, I'd reject such micro-optimizations on their face.
The rule in the nodes/ support files is to list fields in the same
order they're declared in.  There is no chance that it's worth
deviating from that for this.

I can believe that there'd be value in, say, comparing all
scalar fields before all non-scalar ones.  But piecemeal hacks
wouldn't be the way to handle that either.  In any case, I'd
prefer to implement such a plan within the infrastructure to
auto-generate these files that Andres keeps muttering about.

> a. including a function call in the foreach macro is not a practise
> that we really follow. It's true that the macro now assigns the 2nd
> param to a variable. Previous to 1cff1b95ab6 this was not the case and
> it's likely best not to leave any bad examples around that code which
> might get backported might follow.

No, I think you're misremembering.  foreach's second arg is
single-evaluation in all branches.  There were some preliminary
versions of 1cff1b95ab6 in which it would not have been, but that
was sufficiently dangerous that I found a way to get rid of it.

> b. We generally subtract InvalidAttrNumber from varattno when
> including in a Bitmapset.

ITYM FirstLowInvalidHeapAttributeNumber, but yeah.  Otherwise
the code fails on system columns, and there's seldom a good
reason to risk that.

                        regards, tom lane


Reply | Threaded
Open this post in threaded view
|

Re: [PATCH] Keeps tracking the uniqueness with UniqueKey

Andy Fan
In reply to this post by David Rowley
Thanks David for your time,  I will acknowledge every item you mentioned 
with the updated patch.  Now I just talk about part of them.


1. There seem to be some cases where joins are no longer being
detected as unique. This is evident in postgres_fdw.out. We shouldn't
be regressing any of these cases.

You are correct,  the issue here is  I didn't distinguish the one_row case 
in UniqueKey struct.  Actually when a outer relation is join with a relation
which has only one row,  there must be at most one row match the outer join.
The only-one-row case in postgres_fdw.out come from aggregation 
call. I will added one more field "bool onerow" in UniqueKey struct.  and
also try your optimization suggestion for the onerow UniqueKey.
 
2. The following change does not seem like it should be part of this
patch.  I understand you perhaps have done as you think it will
improve the performance of checking if an expression is in a list of
expressions.

- COMPARE_SCALAR_FIELD(varno);
+ /* Compare varattno first since it has higher selectivity than varno */
  COMPARE_SCALAR_FIELD(varattno);
+ COMPARE_SCALAR_FIELD(varno);

I did have a hesitation when I make this changes.  so I'd rollback this change
at the following patch. 
 
If you think that is true, then please do it as a separate effort and
provide benchmarks with your findings.

3. list_all_members_in. I think this would be better named as
list_is_subset. Please follow the lead of bms_is_subset().
Additionally, you should Assert that IsPointerList is true as there's
nothing else to indicate that it can't be used for an int or Oid list.

4. guarantee is not a very good name for the field in UniqueKey.
Maybe something like is_not_null?

 
5. I think you should be performing a bms_del_member during join
removal rather than removing this Assert()

- Assert(bms_equal(rel->relids, root->all_baserels));

FWIW, it's far from perfect that you've needed to delay the left join
removal, but I do understand why you've done it. It's also far from
perfect that you're including removed relations in the
total_table_pages calculation. c6e4133fae1 took some measures to
improve this calculation and this is making it worse again.

Since the removed relation depends on the UniqueKey which has to be
calculated after  total_table_pages calculation in current code, so that's 
something I must do.  But if the relation is not removable,  there is no waste
at all.  If it is removable,  such gain will much higher than the loss.  I'm 
not sure this should be a concern.   

Actually looks the current remove_useless_join has some limits which can't
remove a joinrel,  I still didn't figure out why.  In the past we have some limited
ability to detect the unqiueness after join, so that's would be ok.  Since  we have
such ability now,  this may be another opportunity to improve the join_is_removable
function, but I'd not like put such thing in this patch. 

Since you said "far from perfect" twice for this point and I only get one reason (we 
may plan a node which we removed later),  do I miss the other one? 

6. Can you explain why you moved the populate_baserel_uniquekeys()
call out of set_plain_rel_size()?

This is to be consistent with populate_partitionedrel_uniquekeys, which
is set at set_append_rel_pathlist.  
  
7. I don't think the removal of rel_supports_distinctness() is
warranted.  Is it not ok to check if the relation has any uniquekeys?

I think this is a good suggestion.  I will follow that.  

8. Your spelling of unique is incorrect in many places:

src/backend/nodes/makefuncs.c: * makeUnqiueKey
src/backend/optimizer/path/uniquekeys.c:static List
*initililze_unqiuecontext_for_joinrel(RelOptInfo *joinrel,
src/backend/optimizer/path/uniquekeys.c: * check if combination of
unqiuekeys from both side is still useful for us,
src/backend/optimizer/path/uniquekeys.c:        outerrel_uniquekey_ctx
= initililze_unqiuecontext_for_joinrel(joinrel, outerrel);
src/backend/optimizer/path/uniquekeys.c:        innerrel_uniquekey_ctx
= initililze_unqiuecontext_for_joinrel(joinrel, innerrel);
src/backend/optimizer/path/uniquekeys.c: * we need to convert the
UnqiueKey from sub_final_rel to currel via the positions info in
src/backend/optimizer/path/uniquekeys.c:                ctx->pos =
pos; /* the position in current targetlist,  will be used to set
UnqiueKey */
src/backend/optimizer/path/uniquekeys.c: * Check if Unqiue key of the
innerrel is valid after join. innerrel's UniqueKey
src/backend/optimizer/path/uniquekeys.c: * initililze_unqiuecontext_for_joinrel
src/backend/optimizer/path/uniquekeys.c: * all the unqiuekeys which
are not possible to use later
src/backend/optimizer/path/uniquekeys.c:initililze_unqiuecontext_for_joinrel(RelOptInfo
*joinrel,  RelOptInfo *inputrel)
src/backend/optimizer/plan/analyzejoins.c:                      /*
This UnqiueKey is what we want */
src/backend/optimizer/plan/planner.c:   /* If we the result if unqiue
already, we just return the input_rel directly */
src/include/nodes/pathnodes.h: * exprs is a list of exprs which is
unqiue on current RelOptInfo.
src/test/regress/expected/join.out:-- XXXX: since b.id is unqiue now
so the group by cluase is erased, so
src/test/regress/expected/select_distinct.out:-- create unqiue index on dist_p
src/test/regress/expected/select_distinct.out:-- we also support
create unqiue index on each child tables
src/test/regress/sql/join.sql:-- XXXX: since b.id is unqiue now so the
group by cluase is erased, so
src/test/regress/sql/select_distinct.sql:-- create unqiue index on dist_p
src/test/regress/sql/select_distinct.sql:-- we also support create
unqiue index on each child tables

9. A few things wrong with the following fragment:

/* set the not null info now */
ListCell *lc;
foreach(lc, find_nonnullable_vars(qual))
{
Var *var = lfirst_node(Var, lc);
RelOptInfo *rel = root->simple_rel_array[var->varno];
if (var->varattno > InvalidAttrNumber)
rel->not_null_cols = bms_add_member(rel->not_null_cols, var->varattno);
}

a. including a function call in the foreach macro is not a practise
that we really follow. It's true that the macro now assigns the 2nd
param to a variable. Previous to 1cff1b95ab6 this was not the case and
it's likely best not to leave any bad examples around that code which
might get backported might follow.
b. We generally subtract InvalidAttrNumber from varattno when
including in a Bitmapset.
c. not_null_cols is not well named. I think notnullattrs
d. not_null_cols should not be a Relids type, it should be Bitmapset.

If it is a Bitmapset,  we have to pass it with "&" usually.  is it our practice? 
 
10. add_uniquekey_for_onerow() seems pretty wasteful.  Is there really
a need to add each item in the rel's targetlist to the uniquekey list?
What if we just add an empty list to the unique keys, that way if we
need to test if some expr is a superset of any uniquekey, then we'll
see it is as any set is a superset of an empty set.  Likely the empty
set of uniquekeys should be the only one in the rel's uniquekey list.

11. In create_distinct_paths() the code is now calling
get_sortgrouplist_exprs() multiple times with the same input. I think
it would be better to just call it once and set the result in a local
variable.

12. The comment in the code below is not true. The List contains
Lists, of which contain UniqueKeys

List    *uniquekeys; /* List of UniqueKey */

It is a list of UniqueKey,  the UniqueKey can have a list of exprs. 
 
13. I'm having trouble parsing the final sentence in:

+ * can only guarantee the uniqueness without considering the null values. This
+ * field is necessary for remove_useless_join & reduce_unique_semijions since
+ * these cases don't care about the null values.

Why is the field which stores the nullability of the key required for
code that does not care about the nullability of the key?

The guarantee is introduced to for the following cases:

create table t1 (a int primary key, b int);
create table t2 (a int primary key, b int);
select .. from t1,  (select b from t2 group by t2) t2 ..;

-- b is nullable.  so t2(b) can't be a normal UniqueKey (which means b may have some 
duplicated rows)
create unique index t2_uk_b on t2(b);  

-- the left join still can be removed since t2.b is a unique index and the nullable 
doesn't matter here.
select t1.* from t1 left join t2 on (t1.b = t2.b);  

do you think we have can do some optimization in this case? I don't understand 
your question well. 
 
15. The tests you've changed the expected outcome of in join.out
should be updated so that the GROUP BY and DISTINCT clause is not
removed. This will allow the test to continue testing what it was
intended to test. You can do this by changing the columns in the GROUP
BY clause so that the new code does not find uniquekeys for those
columns.   

Thanks for your explanation, very impressive!
 
16. The tests in aggregates.out are in a similar situation. There are
various tests trying to ensure that remove_useless_groupby_columns()
does what it's meant to do. You can modify these tests to add a join
which is non-unique to effectively duplicate the PK column.

17. In your select_distinct tests, can you move away from naming the
tables starting with select_distinct?  It makes reading queries pretty
hard.

e.g. explain (costs off) select distinct uk1, uk2 from
select_distinct_a where uk2 is not null;

When I first glanced that, I failed to see the underscores and the
query looked invalid.

18. Check the spelling if "erased". You have it spelt as "ereased" in
a couple of locations.

OK,  I just installed a spell check plugin for my editor, hope it will catch such
errors next time. 
 
 
19. Please pay attention to the capitalisation of SQL keywords in the
test files you've modified. I understand we're very inconsistent in
this department in general, but we do at least try not to mix
capitalisation within the same file.  Basically, please upper case the
keywords in select_distinct.sql

20. In addition to the above, please try to wrap long SQL lines so
they're below 80 chars.

I'll review the patch in more detail once the above points have been addressed.

David
Reply | Threaded
Open this post in threaded view
|

Re: [PATCH] Keeps tracking the uniqueness with UniqueKey

David Rowley
On Wed, 1 Apr 2020 at 13:45, Andy Fan <[hidden email]> wrote:

>> 5. I think you should be performing a bms_del_member during join
>> removal rather than removing this Assert()
>>
>> - Assert(bms_equal(rel->relids, root->all_baserels));
>>
>> FWIW, it's far from perfect that you've needed to delay the left join
>> removal, but I do understand why you've done it. It's also far from
>> perfect that you're including removed relations in the
>> total_table_pages calculation. c6e4133fae1 took some measures to
>> improve this calculation and this is making it worse again.
>>
> Since the removed relation depends on the UniqueKey which has to be
> calculated after  total_table_pages calculation in current code, so that's
> something I must do.  But if the relation is not removable,  there is no waste
> at all.  If it is removable,  such gain will much higher than the loss.  I'm
> not sure this should be a concern.

The reason join removals was done so early in planning before was to
save the planner from having to do additional work for relations which
were going to be removed later.  For example, building path lists.

> Actually looks the current remove_useless_join has some limits which can't
> remove a joinrel,  I still didn't figure out why.  In the past we have some limited
> ability to detect the unqiueness after join, so that's would be ok.  Since  we have
> such ability now,  this may be another opportunity to improve the join_is_removable
> function, but I'd not like put such thing in this patch.

Yeah, there's certainly more left join shapes that we could remove.
e.g when the left join relation is not a singleton rel.  We shouldn't
do anything to purposefully block additional join removals as a result
of adding UniqueKeys, but likely shouldn't go to any trouble to make
additional ones work. That can be done later.

> Since you said "far from perfect" twice for this point and I only get one reason (we
> may plan a node which we removed later),  do I miss the other one?

a) additional planning work by not removing the join sooner. b) wrong
total page calculation.

In theory b) could be fixed by subtracting the removed join rels pages
after we remove it, but unfortunately, there's no point since we've
built the paths by that time already and we really only use the value
to determine how much IO is going to be random vs sequential, which is
determined during set_base_rel_pathlists()

>> d. not_null_cols should not be a Relids type, it should be Bitmapset.
>>
> If it is a Bitmapset,  we have to pass it with "&" usually.  is it our practice?

Well, a Bitmapset pointer.   Relids is saved for range table indexes.
Storing anything else in there is likely to lead to confusion.

>> 12. The comment in the code below is not true. The List contains
>> Lists, of which contain UniqueKeys
>>
>> List    *uniquekeys; /* List of UniqueKey */
>>
> It is a list of UniqueKey,  the UniqueKey can have a list of exprs.

Hmm, so this is what I called a UniqueKeySet in the original patch.
I'm a bit divided by that change. With PathKeys, technically you can
make use of a Path with a given set of PathKeys if you only require
some leading subset of those keys.  That's not the case for
UniqueKeys, it's all or nothing, so perhaps having the singular name
is better than the plural name I gave it. However, I'm not certain.

(Really PathKey does not seem like a great name in the first place
since it has nothing to do with keys)

>> 13. I'm having trouble parsing the final sentence in:
>>
>> + * can only guarantee the uniqueness without considering the null values. This
>> + * field is necessary for remove_useless_join & reduce_unique_semijions since
>> + * these cases don't care about the null values.
>>
>> Why is the field which stores the nullability of the key required for
>> code that does not care about the nullability of the key?
>>
> The guarantee is introduced to for the following cases:
>
> create table t1 (a int primary key, b int);
> create table t2 (a int primary key, b int);
> select .. from t1,  (select b from t2 group by t2) t2 ..;
>
> -- b is nullable.  so t2(b) can't be a normal UniqueKey (which means b may have some
> duplicated rows)
> create unique index t2_uk_b on t2(b);
>
> -- the left join still can be removed since t2.b is a unique index and the nullable
> doesn't matter here.
> select t1.* from t1 left join t2 on (t1.b = t2.b);
>
> do you think we have can do some optimization in this case? I don't understand
> your question well.

OK, so by "don't care", you mean, don't duplicate NULL values.  I
assumed you had meant that it does not matter either way, as in: don't
mind if there are NULL values or not. It might be best to have a go at
changing the wording to be more explicit to what you mean there.