Details

    • New Feature
    • Status: Open (View Workflow)
    • Critical
    • Resolution: Unresolved
    • 12.2
    • None
    • None

    Description

      We want to make Items reentrant, so calculation can be distributed between different processors. This will be very useful for UNIONs, but possible use cases will not be really limited only to UNIONs.

      Currently there are the following obstacles to make Items reentrant:

      1. Item::null_value

      The member Item::null_value. It should be removed. Value getter methods should be rewritten to return the value together with the null flag. There are two options here:

      • a. Remove all non-reentrant data type specific methods: val_int(), val_bool(), val_real() and replace them by a single method {code:cpp}bool Item::val(Value *);{code} See MDEV-19259
      • b. Modify the existing data type specific methods to return null flag together with the value itself. Possible options, using double as an example:{code:cpp}
        virtual double val_real_null(bool *null_value_arg)= 0; // Add a pointer to null flag
        virtual bool get_double(double *to)= 0; // return NULL flag, pass the destination by pointer
        virtual Double_null to_double_null()= 0; // return a structure {double,bool}
        {code}
        See MDEV-23738 for more details.

      2. Temporary values (e.g. Item::str_value, Item_func_xxx::tmp_value)

      Many Item descendants, and especially Item_func*, store various intermediate String values inside themselves, as members.

      Some examples:

      class Item_func_ord :public Item_int_func
      {
        String value;
      public:
        ...
      };
      

      class Item_func_md5 :public Item_str_ascii\_func
      {
        String tmp\_value;
      public:
       ...
      }
      

      class Item_func_date_format :public Item_str\_func
      \{
        int fixed\_length;
        const bool is_time_format;
        String value;
      public:
        ...
      \}
      

      All these members should be removed.

      The reasonably short values should be moved on stack,
      e.g. using the StringBuffer<size> template.

      The long values should be moved to THD, as a sort of String pool.

      The method

      String *Item::val\_str(String *to);
      

      should be turned to:

      String *Item::val\_str(String *to, String\_pool \*pool) const;
      

      Or, possibly, even to:

      String *Item::val_str(String_pool *pool) const;
      

      so the final String value can also be allocated on String_pool.

      String_pool can have a constructor accepting a String object:

      String\_pool(String \*str);
      

      to keep polymorphism, so the old code still works:

      String buffer, \*tmp= item\->val\_str(&buffer);
      

      The above call will be convenient for the cases when we don't need to reuse the memory allocated by intermediate values during Item->val_str() calculation.

      Attachments

        Issue Links

          Activity

            I don't know whether it's a good approach. There are other fields in Item that prevent it from being reentrant.
            Instead of solving it on a field-by-field basis we could create a hierarchy of "Item_runtime_context" objects. String values will naturally belong there too.

            serg Sergei Golubchik added a comment - I don't know whether it's a good approach. There are other fields in Item that prevent it from being reentrant. Instead of solving it on a field-by-field basis we could create a hierarchy of "Item_runtime_context" objects. String values will naturally belong there too.

            With Monty we discussed 2 main methods to make it (+ mix of both):
            1) Use "Value" object which will be passed across Items and store value
            2) Item uses memory region in THD by offset to store data they need

            sanja Oleksandr Byelkin added a comment - With Monty we discussed 2 main methods to make it (+ mix of both): 1) Use "Value" object which will be passed across Items and store value 2) Item uses memory region in THD by offset to store data they need

            As it was discussed on Helsinki meeting we do:

            1) value class and use it where it possible
            2) other data can be stored in THD memory region and offset to allocated data can be stored on prepare

            Nearest task is to make "value" object returned as result of Item::val() and try to replace all top calls of val_*() with it.

            sanja Oleksandr Byelkin added a comment - As it was discussed on Helsinki meeting we do: 1) value class and use it where it possible 2) other data can be stored in THD memory region and offset to allocated data can be stored on prepare Nearest task is to make "value" object returned as result of Item::val() and try to replace all top calls of val_*() with it.
            sanja Oleksandr Byelkin added a comment - - edited

            Data stored in the Item are one of 3 type (by Serg):

            • Part of the value
              • null_value
            • Metadata of the Item (shoud left in the Item)
              • can be null
              • with sum func
              • collation
              • ...
            • Run-time state (shoud be moved in THD)
              • null_value (sometimes)
              • accumulators for aggregates
              • ...
            sanja Oleksandr Byelkin added a comment - - edited Data stored in the Item are one of 3 type (by Serg): Part of the value null_value Metadata of the Item (shoud left in the Item) can be null with sum func collation ... Run-time state (shoud be moved in THD) null_value (sometimes) accumulators for aggregates ...

            People

              bar Alexander Barkov
              bar Alexander Barkov
              Votes:
              3 Vote for this issue
              Watchers:
              9 Start watching this issue

              Dates

                Created:
                Updated:

                Git Integration

                  Error rendering 'com.xiplink.jira.git.jira_git_plugin:git-issue-webpanel'. Please contact your Jira administrators.