Re: POC, WIP: OR-clause support for indexes

В письме от среда, 17 июля 2024 г. 22:36:19 MSK пользователь Alexander
Korotkov написал:

Hi All!

I am continue reading the patch, now it's newer version

First main question:

As far a I can get, the entry point for OR->ANY convertation have been moved
to match_clause_to_indexcol funtion, that checks if some restriction can use
index for performance.

The thing I do not understand what match_clause_to_indexcol actually received
as arguments. Should this be set of expressions with OR in between grouped by
one of the expression argument?

If not I do not understand how this ever should work.

The rest is about code readability

> + if (bms_is_member(index->rel->relid, rinfo->right_relids))
> + return NULL;

This check it totally not obvious for person who is not deep into postgres
code. There should go comment explaining what are we checking for, and why it
does not suit our purposes

> + foreach(lc, orclause->args)
> + {
Being no great expert in postgres code, I am confused what are we iterating on
here? Two arguments of OR statement? (a>1) OR (b>2) those in brackets? Or
what? Comment explaining that would be a great help here.

> +if (sub_rinfo->is_pushed_down != rinfo->is_pushed_down ||
> + sub_rinfo->is_clone != rinfo->is_clone ||
> + sub_rinfo->security_level != rinfo->security_level ||
> + !bms_equal(sub_rinfo->required_relids, rinfo->required_relids) ||
> + !bms_equal(sub_rinfo->incompatible_relids, rinfo-
incompatible_relids) ||
> + !bms_equal(sub_rinfo->outer_relids, rinfo->outer_relids))
> + {

This check it totally mind-blowing... What in the name of existence is going
on here?

I would suggest to split these checks into parts (compiler optimizer should
take care about overhead) and give each part a sane explanation.

--
Nikolay Shaplov aka Nataraj
Fuzzing Engineer at Postgres Professional
Matrix IM: @dhyan:nataraj.su