maria-developers team mailing list archive

[Sergei Golubchik <serg@xxxxxxxxxxx>]

Hi, Alexey!

On Jun 04, Alexey Mogilyovkin wrote:
> For the last week I was making some investigations about implementing my
> task.
> Here are my thoughts about how it can be done.
> I want to find all virtual columns that are used in most outer select. Then
> try to match expressions in where clauses with vcols and rewrite all
> matching ones, including ones in subselects. Then run new Item processor.
> When this processor encounters Item_subselect it finds all vcolumns again,
> but this time only that belongs to subselect. Then the process continues
> recursively.

I'd suggest to ignore subselects now, and only rewrite the top-level
select. After that'll work, you can look into subselects, but there's no
need to try to do everything at once.

> I currently trying to implement it. Code is available here
> https://github.com/ZeroICQ/server/compare/10.4...ZeroICQ:MDEV-6017
> Selects with joins and unions would require some modifications.

normally, iterators are used like

  while (Item *item= it++) { ... }

not with it.peek()

> I had most troubles with getting all where clauses from subselects.
> I am not sure if "if ((*vf)->get_possible_keys().to_ulonglong())" is the

Better:

  if (!(*vf)->get_possible_keys().is_clear_all())

or simply

  if (!(*vf)->part_of_key.is_clear_all())

as get_possible_keys() is just confusing in this context.

> right way to check if there are any suitable indexes for given virtual
> column.  And I have some troubles understanding structure of LEX
> variable after parsing complex queries with joins, subselects and
> unions.

You might get more specific answers if you'd ask more specific questions :)

Regards,
Sergei
Chief Architect MariaDB
and security@xxxxxxxxxxx