bb-10.6-MDEV-33314, please review.

ralf.gebhardt, the problem and the fix will be still valid for the ES.

There is only one thing: I might need to adjust the patch's testcase to use > 128 indexes (currently it uses 100). The rest of the patch is valid.

@spetruna, how do you plan to choose the fields that we should create a pseudo index for?
I assume we should first use fields that are used with an operator we can use with the range optimizer ?
It looks like table->cond_set that is used is already setting the bit's for 'field op constant'
If there are more than 128 of them, which ones to choose?
The first 128 that we find in create_key_parts_for_pseudo_index() ?

Another option would be to change SEL_TREE::keys_map to have an explicit key map allocated in get_mm_parts()
This would allows to have any number of pseudo keys.

Review comments:

In the test case, you should create MAX_INDEXES + 1 fields and conditions.

To do that, please add system variable, MAX_INDEXES. This can be genrally
usefull (simlar to version_malloc_library).

• double rows;
  + double rows= table_records;

You can remove the rows variable and replace it with
a local variable in the only part where it is needed:

rows= records_in_column_ranges(&param, idx, key);
->
double rows= records_in_column_ranges(&param, idx, key);

I have one open question:

• Each SEL_TREE has a key bitmap.
  When we do a tree_and() we merge the bitmaps (and thus assume each bit
  maps to the same index).

For pseudo trees, do we ever try to merge or combine the bitmaps?

I spent some time looking at the code and it is probably safe as we never
combine two SEL_ARG trees generated from different get_mm_trees.

igor, look:

create_key_parts_for_pseudo_indexes() uses this piece of code to check whether to create pseudo indexes for columns:

  for (field_ptr= table->field; *field_ptr; field_ptr++)

  {

    Field *field= *field_ptr;

    if (bitmap_is_set(used_fields, field->field_index) &&

        is_eits_usable(field))

      parts++;

  }

So are you suggesting that outside of create_key_parts_for_pseudo_indexes there should be identical code that walks through the columns, checks "if_eits_usable" and collects a bitmap of first 64 columns, then calls create_key_parts_for_pseudo_indexes().

Since you request not to touch create_key_parts_for_pseudo_indexes(), it will check "if_eits_usable" for each passed column again.

Is that what you would prefer to see implemented? Please clarify.

Slo we do need to change create_key_parts_for_pseudo_indexes after all? Ok let me try making a patch.

igor could you please review the latest patch: https://github.com/MariaDB/server/commit/2949128be1ffd7c340676618b83145f4f3f3929b
I believe it addressed all of your input. it's pushed into bb-10.6-MDEV-33314

I don't see any problems with the patch. Yet as it's a crashing bug the patch should be applied to 10.5 as well.

Notes for the changelog:

The server could crash if a query's WHERE clause has conditions over more than 128 (Enterprise Server) or 64 (Community Server) columns such that column statistics is available for them.