Details

    • 10.2.0-5, 10.2.0-6, 10.2.0-7, 10.2.0-8, 10.2.2-1, 10.2.2-2, 10.2.2-3, 10.2.2-4

    Description

      There is a class of window functions that can be computed on the fly, after ordering. These functions are:

      • rank (DONE)
      • dense_rank (DONE)
      • row_number (DONE)
      • first_value (this is frame-based) (DONE)

      These functions can be computed directly. In order to do this we must:

      1. Sort the rows.
      2. Detect partition boundaries (on the fly as well)
      3. Given partition boundaries, compute the corresponding function value, for each row.

      Two-pass window functions:

      • percent_rank (test implementation needs review)
      • cume_dist (see MDEV-9746)
      • ntile
      • nth_value (this is frame-based) (DONE)
      • last_value (this is frame-based) (DONE)
        these require two passes over partition to compute. The extra information that we require is the number of rows in the partition. In order to find the number of rows, we must first detect partition boundaries and then we can compute the number of rows per partition.

      Two-cursor window functions:

      • lag (DONE)
      • lead (DONE)
        these require an additional cursor that is traveling n rows ahead/behind the current_row cursor.

      Key pieces for implementing this:

      • Make use of the filesort interface, since we do not need temporary tables for these functions.
      • It is a very similar use case to the GROUP BY statement. An important task is figuring out partition boundaries. The classes used for computing GROUP BY, might prove useful.

      Attachments

        Issue Links

          Activity

            cvicentiu Vicențiu Ciorbaru created issue -
            cvicentiu Vicențiu Ciorbaru made changes -
            Field Original Value New Value
            Description There is a class of window functions that can be computed on the fly, after ordering. These functions are:
            * rank
            * dense_rank
            * row_number

            These functions can be computed directly. In order to do this we must:
            # Sort the rows.
            # Detect partition boundaries (on the fly as well)
            # Given partition boundaries, compute the corresponding function value, for each row.

            A second set of functions:
            * percent_rank
            * ntile
            Can be computed given two passes. The extra information that we require is the number of rows in the partition. In order to find the number of rows, we must first detect partition boundaries and then we can compute the number of rows per partition.

            Key pieces for implementing this:
            * Make use of the filesort interface, since we do not need temporary tables for these functions.
            * It is a very similar use case to the GROUP BY statement. An important task is figuring out partition boundaries. The classes used for computing GROUP BY, might prove useful.

            CC: Sergei Petrunia, Igor Babaev, Oleksandr Byelkin
            There is a class of window functions that can be computed on the fly, after ordering. These functions are:
            * rank
            * dense_rank
            * row_number

            These functions can be computed directly. In order to do this we must:
            # Sort the rows.
            # Detect partition boundaries (on the fly as well)
            # Given partition boundaries, compute the corresponding function value, for each row.

            A second set of functions:
            * percent_rank
            * ntile
            Can be computed given two passes. The extra information that we require is the number of rows in the partition. In order to find the number of rows, we must first detect partition boundaries and then we can compute the number of rows per partition.

            Key pieces for implementing this:
            * Make use of the filesort interface, since we do not need temporary tables for these functions.
            * It is a very similar use case to the GROUP BY statement. An important task is figuring out partition boundaries. The classes used for computing GROUP BY, might prove useful.
            psergei Sergei Petrunia made changes -
            ratzpo Rasmus Johansson (Inactive) made changes -
            Workflow MariaDB v2 [ 60755 ] MariaDB v3 [ 64832 ]
            ratzpo Rasmus Johansson (Inactive) made changes -
            Sprint 10.2.0-1 [ 21 ]
            ratzpo Rasmus Johansson (Inactive) made changes -
            Rank Ranked higher
            ratzpo Rasmus Johansson (Inactive) made changes -
            Sprint 10.2.0-1 [ 21 ]
            ratzpo Rasmus Johansson (Inactive) made changes -
            Rank Ranked higher
            ratzpo Rasmus Johansson (Inactive) made changes -
            Sprint 10.2.0-5 [ 32 ]
            ratzpo Rasmus Johansson (Inactive) made changes -
            Rank Ranked higher
            cvicentiu Vicențiu Ciorbaru made changes -
            Sprint 10.2.0-5 [ 32 ] 10.2.0-5, 10.2.0-6 [ 32, 37 ]
            ratzpo Rasmus Johansson (Inactive) made changes -
            Sprint 10.2.0-5, 10.2.0-6 [ 32, 37 ] 10.2.0-5, 10.2.0-6, 10.2.0-7 [ 32, 37, 39 ]
            ratzpo Rasmus Johansson (Inactive) made changes -
            Rank Ranked lower
            cvicentiu Vicențiu Ciorbaru made changes -
            Status Open [ 1 ] In Progress [ 3 ]
            psergei Sergei Petrunia made changes -
            Description There is a class of window functions that can be computed on the fly, after ordering. These functions are:
            * rank
            * dense_rank
            * row_number

            These functions can be computed directly. In order to do this we must:
            # Sort the rows.
            # Detect partition boundaries (on the fly as well)
            # Given partition boundaries, compute the corresponding function value, for each row.

            A second set of functions:
            * percent_rank
            * ntile
            Can be computed given two passes. The extra information that we require is the number of rows in the partition. In order to find the number of rows, we must first detect partition boundaries and then we can compute the number of rows per partition.

            Key pieces for implementing this:
            * Make use of the filesort interface, since we do not need temporary tables for these functions.
            * It is a very similar use case to the GROUP BY statement. An important task is figuring out partition boundaries. The classes used for computing GROUP BY, might prove useful.
            There is a class of window functions that can be computed on the fly, after ordering. These functions are:
            * -rank- (DONE)
            * -dense_rank- (DONE)
            * -row_number- (DONE)
            * first_value

            These functions can be computed directly. In order to do this we must:
            # Sort the rows.
            # Detect partition boundaries (on the fly as well)
            # Given partition boundaries, compute the corresponding function value, for each row.

            A second set of functions:
            * percent_rank
            * cume_dist
            * ntile
            * lag
            * lead
            * nth_value
            * last_value
            Can be computed given two passes. The extra information that we require is the number of rows in the partition. In order to find the number of rows, we must first detect partition boundaries and then we can compute the number of rows per partition.

            Key pieces for implementing this:
            * Make use of the filesort interface, since we do not need temporary tables for these functions.
            * It is a very similar use case to the GROUP BY statement. An important task is figuring out partition boundaries. The classes used for computing GROUP BY, might prove useful.
            psergei Sergei Petrunia made changes -
            Description There is a class of window functions that can be computed on the fly, after ordering. These functions are:
            * -rank- (DONE)
            * -dense_rank- (DONE)
            * -row_number- (DONE)
            * first_value

            These functions can be computed directly. In order to do this we must:
            # Sort the rows.
            # Detect partition boundaries (on the fly as well)
            # Given partition boundaries, compute the corresponding function value, for each row.

            A second set of functions:
            * percent_rank
            * cume_dist
            * ntile
            * lag
            * lead
            * nth_value
            * last_value
            Can be computed given two passes. The extra information that we require is the number of rows in the partition. In order to find the number of rows, we must first detect partition boundaries and then we can compute the number of rows per partition.

            Key pieces for implementing this:
            * Make use of the filesort interface, since we do not need temporary tables for these functions.
            * It is a very similar use case to the GROUP BY statement. An important task is figuring out partition boundaries. The classes used for computing GROUP BY, might prove useful.
            There is a class of window functions that can be computed on the fly, after ordering. These functions are:
            * -rank- (DONE)
            * -dense_rank- (DONE)
            * -row_number- (DONE)
            * first_value

            These functions can be computed directly. In order to do this we must:
            # Sort the rows.
            # Detect partition boundaries (on the fly as well)
            # Given partition boundaries, compute the corresponding function value, for each row.

            A second set of functions:
            * percent_rank (test implementation needs review)
            * cume_dist
            * ntile
            * lag
            * lead
            * nth_value
            * last_value
            Can be computed given two passes. The extra information that we require is the number of rows in the partition. In order to find the number of rows, we must first detect partition boundaries and then we can compute the number of rows per partition.

            Key pieces for implementing this:
            * Make use of the filesort interface, since we do not need temporary tables for these functions.
            * It is a very similar use case to the GROUP BY statement. An important task is figuring out partition boundaries. The classes used for computing GROUP BY, might prove useful.
            psergei Sergei Petrunia made changes -
            Description There is a class of window functions that can be computed on the fly, after ordering. These functions are:
            * -rank- (DONE)
            * -dense_rank- (DONE)
            * -row_number- (DONE)
            * first_value

            These functions can be computed directly. In order to do this we must:
            # Sort the rows.
            # Detect partition boundaries (on the fly as well)
            # Given partition boundaries, compute the corresponding function value, for each row.

            A second set of functions:
            * percent_rank (test implementation needs review)
            * cume_dist
            * ntile
            * lag
            * lead
            * nth_value
            * last_value
            Can be computed given two passes. The extra information that we require is the number of rows in the partition. In order to find the number of rows, we must first detect partition boundaries and then we can compute the number of rows per partition.

            Key pieces for implementing this:
            * Make use of the filesort interface, since we do not need temporary tables for these functions.
            * It is a very similar use case to the GROUP BY statement. An important task is figuring out partition boundaries. The classes used for computing GROUP BY, might prove useful.
            There is a class of window functions that can be computed on the fly, after ordering. These functions are:
            * -rank- (DONE)
            * -dense_rank- (DONE)
            * -row_number- (DONE)
            * first_value

            These functions can be computed directly. In order to do this we must:
            # Sort the rows.
            # Detect partition boundaries (on the fly as well)
            # Given partition boundaries, compute the corresponding function value, for each row.

            A second set of functions:
            * percent_rank (test implementation needs review)
            * cume_dist (test implementation needs review)
            * ntile
            * lag
            * lead
            * nth_value
            * last_value
            Can be computed given two passes. The extra information that we require is the number of rows in the partition. In order to find the number of rows, we must first detect partition boundaries and then we can compute the number of rows per partition.

            Key pieces for implementing this:
            * Make use of the filesort interface, since we do not need temporary tables for these functions.
            * It is a very similar use case to the GROUP BY statement. An important task is figuring out partition boundaries. The classes used for computing GROUP BY, might prove useful.
            psergei Sergei Petrunia made changes -
            Description There is a class of window functions that can be computed on the fly, after ordering. These functions are:
            * -rank- (DONE)
            * -dense_rank- (DONE)
            * -row_number- (DONE)
            * first_value

            These functions can be computed directly. In order to do this we must:
            # Sort the rows.
            # Detect partition boundaries (on the fly as well)
            # Given partition boundaries, compute the corresponding function value, for each row.

            A second set of functions:
            * percent_rank (test implementation needs review)
            * cume_dist (test implementation needs review)
            * ntile
            * lag
            * lead
            * nth_value
            * last_value
            Can be computed given two passes. The extra information that we require is the number of rows in the partition. In order to find the number of rows, we must first detect partition boundaries and then we can compute the number of rows per partition.

            Key pieces for implementing this:
            * Make use of the filesort interface, since we do not need temporary tables for these functions.
            * It is a very similar use case to the GROUP BY statement. An important task is figuring out partition boundaries. The classes used for computing GROUP BY, might prove useful.
            There is a class of window functions that can be computed on the fly, after ordering. These functions are:
            * -rank- (DONE)
            * -dense_rank- (DONE)
            * -row_number- (DONE)
            * first_value

            These functions can be computed directly. In order to do this we must:
            # Sort the rows.
            # Detect partition boundaries (on the fly as well)
            # Given partition boundaries, compute the corresponding function value, for each row.

            A second set of functions:
            * percent_rank (test implementation needs review)
            * cume_dist (test implementation needs review)
            * ntile
            * nth_value
            * last_value
            Can be computed given two passes. The extra information that we require is the number of rows in the partition. In order to find the number of rows, we must first detect partition boundaries and then we can compute the number of rows per partition.

            TODO: how are these functions classified?
            * lag
            * lead

            Key pieces for implementing this:
            * Make use of the filesort interface, since we do not need temporary tables for these functions.
            * It is a very similar use case to the GROUP BY statement. An important task is figuring out partition boundaries. The classes used for computing GROUP BY, might prove useful.
            ratzpo Rasmus Johansson (Inactive) made changes -
            Sprint 10.2.0-5, 10.2.0-6, 10.2.0-7 [ 32, 37, 39 ] 10.2.0-5, 10.2.0-6, 10.2.0-7, 10.2.0-8 [ 32, 37, 39, 41 ]
            ratzpo Rasmus Johansson (Inactive) made changes -
            Rank Ranked lower
            psergei Sergei Petrunia made changes -
            Description There is a class of window functions that can be computed on the fly, after ordering. These functions are:
            * -rank- (DONE)
            * -dense_rank- (DONE)
            * -row_number- (DONE)
            * first_value

            These functions can be computed directly. In order to do this we must:
            # Sort the rows.
            # Detect partition boundaries (on the fly as well)
            # Given partition boundaries, compute the corresponding function value, for each row.

            A second set of functions:
            * percent_rank (test implementation needs review)
            * cume_dist (test implementation needs review)
            * ntile
            * nth_value
            * last_value
            Can be computed given two passes. The extra information that we require is the number of rows in the partition. In order to find the number of rows, we must first detect partition boundaries and then we can compute the number of rows per partition.

            TODO: how are these functions classified?
            * lag
            * lead

            Key pieces for implementing this:
            * Make use of the filesort interface, since we do not need temporary tables for these functions.
            * It is a very similar use case to the GROUP BY statement. An important task is figuring out partition boundaries. The classes used for computing GROUP BY, might prove useful.
            There is a class of window functions that can be computed on the fly, after ordering. These functions are:
            * -rank- (DONE)
            * -dense_rank- (DONE)
            * -row_number- (DONE)
            * first_value

            These functions can be computed directly. In order to do this we must:
            # Sort the rows.
            # Detect partition boundaries (on the fly as well)
            # Given partition boundaries, compute the corresponding function value, for each row.

            Two-pass window functions:
            * percent_rank (test implementation needs review)
            * cume_dist (test implementation needs review)
            * ntile
            * nth_value
            * last_value
            these require two passes over partition to compute. The extra information that we require is the number of rows in the partition. In order to find the number of rows, we must first detect partition boundaries and then we can compute the number of rows per partition.

            TODO: how are these functions classified?
            * lag
            * lead

            Key pieces for implementing this:
            * Make use of the filesort interface, since we do not need temporary tables for these functions.
            * It is a very similar use case to the GROUP BY statement. An important task is figuring out partition boundaries. The classes used for computing GROUP BY, might prove useful.
            psergei Sergei Petrunia made changes -
            Description There is a class of window functions that can be computed on the fly, after ordering. These functions are:
            * -rank- (DONE)
            * -dense_rank- (DONE)
            * -row_number- (DONE)
            * first_value

            These functions can be computed directly. In order to do this we must:
            # Sort the rows.
            # Detect partition boundaries (on the fly as well)
            # Given partition boundaries, compute the corresponding function value, for each row.

            Two-pass window functions:
            * percent_rank (test implementation needs review)
            * cume_dist (test implementation needs review)
            * ntile
            * nth_value
            * last_value
            these require two passes over partition to compute. The extra information that we require is the number of rows in the partition. In order to find the number of rows, we must first detect partition boundaries and then we can compute the number of rows per partition.

            TODO: how are these functions classified?
            * lag
            * lead

            Key pieces for implementing this:
            * Make use of the filesort interface, since we do not need temporary tables for these functions.
            * It is a very similar use case to the GROUP BY statement. An important task is figuring out partition boundaries. The classes used for computing GROUP BY, might prove useful.
            There is a class of window functions that can be computed on the fly, after ordering. These functions are:
            * -rank- (DONE)
            * -dense_rank- (DONE)
            * -row_number- (DONE)
            * first_value

            These functions can be computed directly. In order to do this we must:
            # Sort the rows.
            # Detect partition boundaries (on the fly as well)
            # Given partition boundaries, compute the corresponding function value, for each row.

            Two-pass window functions:
            * percent_rank (test implementation needs review)
            * cume_dist (test implementation needs review)
            * ntile
            * nth_value
            * last_value
            these require two passes over partition to compute. The extra information that we require is the number of rows in the partition. In order to find the number of rows, we must first detect partition boundaries and then we can compute the number of rows per partition.

            Two-cursor window functions:
            * lag
            * lead
            these require an additional cursor that is traveling n rows ahead/behind the current_row cursor.

            Key pieces for implementing this:
            * Make use of the filesort interface, since we do not need temporary tables for these functions.
            * It is a very similar use case to the GROUP BY statement. An important task is figuring out partition boundaries. The classes used for computing GROUP BY, might prove useful.
            psergei Sergei Petrunia made changes -
            Description There is a class of window functions that can be computed on the fly, after ordering. These functions are:
            * -rank- (DONE)
            * -dense_rank- (DONE)
            * -row_number- (DONE)
            * first_value

            These functions can be computed directly. In order to do this we must:
            # Sort the rows.
            # Detect partition boundaries (on the fly as well)
            # Given partition boundaries, compute the corresponding function value, for each row.

            Two-pass window functions:
            * percent_rank (test implementation needs review)
            * cume_dist (test implementation needs review)
            * ntile
            * nth_value
            * last_value
            these require two passes over partition to compute. The extra information that we require is the number of rows in the partition. In order to find the number of rows, we must first detect partition boundaries and then we can compute the number of rows per partition.

            Two-cursor window functions:
            * lag
            * lead
            these require an additional cursor that is traveling n rows ahead/behind the current_row cursor.

            Key pieces for implementing this:
            * Make use of the filesort interface, since we do not need temporary tables for these functions.
            * It is a very similar use case to the GROUP BY statement. An important task is figuring out partition boundaries. The classes used for computing GROUP BY, might prove useful.
            There is a class of window functions that can be computed on the fly, after ordering. These functions are:
            * -rank- (DONE)
            * -dense_rank- (DONE)
            * -row_number- (DONE)
            * first_value (this is frame-based)

            These functions can be computed directly. In order to do this we must:
            # Sort the rows.
            # Detect partition boundaries (on the fly as well)
            # Given partition boundaries, compute the corresponding function value, for each row.

            Two-pass window functions:
            * percent_rank (test implementation needs review)
            * cume_dist (test implementation needs review)
            * ntile
            * nth_value (this is frame-based)
            * last_value (this is frame-based)
            these require two passes over partition to compute. The extra information that we require is the number of rows in the partition. In order to find the number of rows, we must first detect partition boundaries and then we can compute the number of rows per partition.

            Two-cursor window functions:
            * lag
            * lead
            these require an additional cursor that is traveling n rows ahead/behind the current_row cursor.

            Key pieces for implementing this:
            * Make use of the filesort interface, since we do not need temporary tables for these functions.
            * It is a very similar use case to the GROUP BY statement. An important task is figuring out partition boundaries. The classes used for computing GROUP BY, might prove useful.
            psergei Sergei Petrunia made changes -
            Description There is a class of window functions that can be computed on the fly, after ordering. These functions are:
            * -rank- (DONE)
            * -dense_rank- (DONE)
            * -row_number- (DONE)
            * first_value (this is frame-based)

            These functions can be computed directly. In order to do this we must:
            # Sort the rows.
            # Detect partition boundaries (on the fly as well)
            # Given partition boundaries, compute the corresponding function value, for each row.

            Two-pass window functions:
            * percent_rank (test implementation needs review)
            * cume_dist (test implementation needs review)
            * ntile
            * nth_value (this is frame-based)
            * last_value (this is frame-based)
            these require two passes over partition to compute. The extra information that we require is the number of rows in the partition. In order to find the number of rows, we must first detect partition boundaries and then we can compute the number of rows per partition.

            Two-cursor window functions:
            * lag
            * lead
            these require an additional cursor that is traveling n rows ahead/behind the current_row cursor.

            Key pieces for implementing this:
            * Make use of the filesort interface, since we do not need temporary tables for these functions.
            * It is a very similar use case to the GROUP BY statement. An important task is figuring out partition boundaries. The classes used for computing GROUP BY, might prove useful.
            There is a class of window functions that can be computed on the fly, after ordering. These functions are:
            * -rank- (DONE)
            * -dense_rank- (DONE)
            * -row_number- (DONE)
            * first_value (this is frame-based)

            These functions can be computed directly. In order to do this we must:
            # Sort the rows.
            # Detect partition boundaries (on the fly as well)
            # Given partition boundaries, compute the corresponding function value, for each row.

            Two-pass window functions:
            * percent_rank (test implementation needs review)
            * cume_dist (see MDEV-9746)
            * ntile
            * nth_value (this is frame-based)
            * last_value (this is frame-based)
            these require two passes over partition to compute. The extra information that we require is the number of rows in the partition. In order to find the number of rows, we must first detect partition boundaries and then we can compute the number of rows per partition.

            Two-cursor window functions:
            * lag
            * lead
            these require an additional cursor that is traveling n rows ahead/behind the current_row cursor.

            Key pieces for implementing this:
            * Make use of the filesort interface, since we do not need temporary tables for these functions.
            * It is a very similar use case to the GROUP BY statement. An important task is figuring out partition boundaries. The classes used for computing GROUP BY, might prove useful.
            ratzpo Rasmus Johansson (Inactive) made changes -
            Sprint 10.2.0-5, 10.2.0-6, 10.2.0-7, 10.2.0-8 [ 32, 37, 39, 41 ] 10.2.0-5, 10.2.0-6, 10.2.0-7, 10.2.0-8, 10.2.0-9 [ 32, 37, 39, 41, 43 ]
            ratzpo Rasmus Johansson (Inactive) made changes -
            Rank Ranked higher
            ratzpo Rasmus Johansson (Inactive) made changes -
            Sprint 10.2.0-5, 10.2.0-6, 10.2.0-7, 10.2.0-8, 10.2.0-9 [ 32, 37, 39, 41, 43 ] 10.2.0-5, 10.2.0-6, 10.2.0-7, 10.2.0-8 [ 32, 37, 39, 41 ]
            ratzpo Rasmus Johansson (Inactive) made changes -
            Rank Ranked higher
            psergei Sergei Petrunia made changes -
            Description There is a class of window functions that can be computed on the fly, after ordering. These functions are:
            * -rank- (DONE)
            * -dense_rank- (DONE)
            * -row_number- (DONE)
            * first_value (this is frame-based)

            These functions can be computed directly. In order to do this we must:
            # Sort the rows.
            # Detect partition boundaries (on the fly as well)
            # Given partition boundaries, compute the corresponding function value, for each row.

            Two-pass window functions:
            * percent_rank (test implementation needs review)
            * cume_dist (see MDEV-9746)
            * ntile
            * nth_value (this is frame-based)
            * last_value (this is frame-based)
            these require two passes over partition to compute. The extra information that we require is the number of rows in the partition. In order to find the number of rows, we must first detect partition boundaries and then we can compute the number of rows per partition.

            Two-cursor window functions:
            * lag
            * lead
            these require an additional cursor that is traveling n rows ahead/behind the current_row cursor.

            Key pieces for implementing this:
            * Make use of the filesort interface, since we do not need temporary tables for these functions.
            * It is a very similar use case to the GROUP BY statement. An important task is figuring out partition boundaries. The classes used for computing GROUP BY, might prove useful.
            There is a class of window functions that can be computed on the fly, after ordering. These functions are:
            * -rank- (DONE)
            * -dense_rank- (DONE)
            * -row_number- (DONE)
            * first_value (this is frame-based)

            These functions can be computed directly. In order to do this we must:
            # Sort the rows.
            # Detect partition boundaries (on the fly as well)
            # Given partition boundaries, compute the corresponding function value, for each row.

            Two-pass window functions:
            * -percent_rank (test implementation needs review)-
            * -cume_dist (see MDEV-9746)-
            * -ntile-
            * nth_value (this is frame-based)
            * last_value (this is frame-based)
            these require two passes over partition to compute. The extra information that we require is the number of rows in the partition. In order to find the number of rows, we must first detect partition boundaries and then we can compute the number of rows per partition.

            Two-cursor window functions:
            * lag
            * lead
            these require an additional cursor that is traveling n rows ahead/behind the current_row cursor.

            Key pieces for implementing this:
            * Make use of the filesort interface, since we do not need temporary tables for these functions.
            * It is a very similar use case to the GROUP BY statement. An important task is figuring out partition boundaries. The classes used for computing GROUP BY, might prove useful.
            elenst Elena Stepanova made changes -
            Component/s Optimizer - Window functions [ 13502 ]
            ratzpo Rasmus Johansson (Inactive) made changes -
            Sprint 10.2.0-5, 10.2.0-6, 10.2.0-7, 10.2.0-8 [ 32, 37, 39, 41 ] 10.2.0-5, 10.2.0-6, 10.2.0-7, 10.2.0-8, 10.2.2-1 [ 32, 37, 39, 41, 89 ]
            ratzpo Rasmus Johansson (Inactive) made changes -
            Rank Ranked higher
            ratzpo Rasmus Johansson (Inactive) made changes -
            Sprint 10.2.0-5, 10.2.0-6, 10.2.0-7, 10.2.0-8, 10.2.2-1 [ 32, 37, 39, 41, 89 ] 10.2.0-5, 10.2.0-6, 10.2.0-7, 10.2.0-8, 10.2.2-1, 10.2.2-2 [ 32, 37, 39, 41, 89, 92 ]
            ratzpo Rasmus Johansson (Inactive) made changes -
            Rank Ranked lower
            ratzpo Rasmus Johansson (Inactive) made changes -
            Sprint 10.2.0-5, 10.2.0-6, 10.2.0-7, 10.2.0-8, 10.2.2-1, 10.2.2-2 [ 32, 37, 39, 41, 89, 92 ] 10.2.0-5, 10.2.0-6, 10.2.0-7, 10.2.0-8, 10.2.2-1, 10.2.2-2, 10.2.2-3 [ 32, 37, 39, 41, 89, 92, 94 ]
            ratzpo Rasmus Johansson (Inactive) made changes -
            Sprint 10.2.0-5, 10.2.0-6, 10.2.0-7, 10.2.0-8, 10.2.2-1, 10.2.2-2, 10.2.2-3 [ 32, 37, 39, 41, 89, 92, 94 ] 10.2.0-5, 10.2.0-6, 10.2.0-7, 10.2.0-8, 10.2.2-1, 10.2.2-2, 10.2.2-3, 10.2.2-4 [ 32, 37, 39, 41, 89, 92, 94, 96 ]
            cvicentiu Vicențiu Ciorbaru made changes -
            Description There is a class of window functions that can be computed on the fly, after ordering. These functions are:
            * -rank- (DONE)
            * -dense_rank- (DONE)
            * -row_number- (DONE)
            * first_value (this is frame-based)

            These functions can be computed directly. In order to do this we must:
            # Sort the rows.
            # Detect partition boundaries (on the fly as well)
            # Given partition boundaries, compute the corresponding function value, for each row.

            Two-pass window functions:
            * -percent_rank (test implementation needs review)-
            * -cume_dist (see MDEV-9746)-
            * -ntile-
            * nth_value (this is frame-based)
            * last_value (this is frame-based)
            these require two passes over partition to compute. The extra information that we require is the number of rows in the partition. In order to find the number of rows, we must first detect partition boundaries and then we can compute the number of rows per partition.

            Two-cursor window functions:
            * lag
            * lead
            these require an additional cursor that is traveling n rows ahead/behind the current_row cursor.

            Key pieces for implementing this:
            * Make use of the filesort interface, since we do not need temporary tables for these functions.
            * It is a very similar use case to the GROUP BY statement. An important task is figuring out partition boundaries. The classes used for computing GROUP BY, might prove useful.
            There is a class of window functions that can be computed on the fly, after ordering. These functions are:
            * -rank- (DONE)
            * -dense_rank- (DONE)
            * -row_number- (DONE)
            * -first_value (this is frame-based)- (DONE)

            These functions can be computed directly. In order to do this we must:
            # Sort the rows.
            # Detect partition boundaries (on the fly as well)
            # Given partition boundaries, compute the corresponding function value, for each row.

            Two-pass window functions:
            * -percent_rank (test implementation needs review)-
            * -cume_dist (see MDEV-9746)-
            * -ntile-
            * nth_value (this is frame-based)
            * last_value (this is frame-based)
            these require two passes over partition to compute. The extra information that we require is the number of rows in the partition. In order to find the number of rows, we must first detect partition boundaries and then we can compute the number of rows per partition.

            Two-cursor window functions:
            * lag
            * lead
            these require an additional cursor that is traveling n rows ahead/behind the current_row cursor.

            Key pieces for implementing this:
            * Make use of the filesort interface, since we do not need temporary tables for these functions.
            * It is a very similar use case to the GROUP BY statement. An important task is figuring out partition boundaries. The classes used for computing GROUP BY, might prove useful.
            cvicentiu Vicențiu Ciorbaru made changes -
            Description There is a class of window functions that can be computed on the fly, after ordering. These functions are:
            * -rank- (DONE)
            * -dense_rank- (DONE)
            * -row_number- (DONE)
            * -first_value (this is frame-based)- (DONE)

            These functions can be computed directly. In order to do this we must:
            # Sort the rows.
            # Detect partition boundaries (on the fly as well)
            # Given partition boundaries, compute the corresponding function value, for each row.

            Two-pass window functions:
            * -percent_rank (test implementation needs review)-
            * -cume_dist (see MDEV-9746)-
            * -ntile-
            * nth_value (this is frame-based)
            * last_value (this is frame-based)
            these require two passes over partition to compute. The extra information that we require is the number of rows in the partition. In order to find the number of rows, we must first detect partition boundaries and then we can compute the number of rows per partition.

            Two-cursor window functions:
            * lag
            * lead
            these require an additional cursor that is traveling n rows ahead/behind the current_row cursor.

            Key pieces for implementing this:
            * Make use of the filesort interface, since we do not need temporary tables for these functions.
            * It is a very similar use case to the GROUP BY statement. An important task is figuring out partition boundaries. The classes used for computing GROUP BY, might prove useful.
            There is a class of window functions that can be computed on the fly, after ordering. These functions are:
            * -rank- (DONE)
            * -dense_rank- (DONE)
            * -row_number- (DONE)
            * -first_value (this is frame-based)- (DONE)

            These functions can be computed directly. In order to do this we must:
            # Sort the rows.
            # Detect partition boundaries (on the fly as well)
            # Given partition boundaries, compute the corresponding function value, for each row.

            Two-pass window functions:
            * -percent_rank (test implementation needs review)-
            * -cume_dist (see MDEV-9746)-
            * -ntile-
            * nth_value (this is frame-based)
            * -last_value (this is frame-based)- (DONE)
            these require two passes over partition to compute. The extra information that we require is the number of rows in the partition. In order to find the number of rows, we must first detect partition boundaries and then we can compute the number of rows per partition.

            Two-cursor window functions:
            * lag
            * lead
            these require an additional cursor that is traveling n rows ahead/behind the current_row cursor.

            Key pieces for implementing this:
            * Make use of the filesort interface, since we do not need temporary tables for these functions.
            * It is a very similar use case to the GROUP BY statement. An important task is figuring out partition boundaries. The classes used for computing GROUP BY, might prove useful.
            cvicentiu Vicențiu Ciorbaru made changes -
            Fix Version/s 10.2.2 [ 22013 ]
            Fix Version/s 10.2 [ 14601 ]
            Resolution Fixed [ 1 ]
            Status In Progress [ 3 ] Closed [ 6 ]
            cvicentiu Vicențiu Ciorbaru made changes -
            Description There is a class of window functions that can be computed on the fly, after ordering. These functions are:
            * -rank- (DONE)
            * -dense_rank- (DONE)
            * -row_number- (DONE)
            * -first_value (this is frame-based)- (DONE)

            These functions can be computed directly. In order to do this we must:
            # Sort the rows.
            # Detect partition boundaries (on the fly as well)
            # Given partition boundaries, compute the corresponding function value, for each row.

            Two-pass window functions:
            * -percent_rank (test implementation needs review)-
            * -cume_dist (see MDEV-9746)-
            * -ntile-
            * nth_value (this is frame-based)
            * -last_value (this is frame-based)- (DONE)
            these require two passes over partition to compute. The extra information that we require is the number of rows in the partition. In order to find the number of rows, we must first detect partition boundaries and then we can compute the number of rows per partition.

            Two-cursor window functions:
            * lag
            * lead
            these require an additional cursor that is traveling n rows ahead/behind the current_row cursor.

            Key pieces for implementing this:
            * Make use of the filesort interface, since we do not need temporary tables for these functions.
            * It is a very similar use case to the GROUP BY statement. An important task is figuring out partition boundaries. The classes used for computing GROUP BY, might prove useful.
            There is a class of window functions that can be computed on the fly, after ordering. These functions are:
            * -rank- (DONE)
            * -dense_rank- (DONE)
            * -row_number- (DONE)
            * -first_value (this is frame-based)- (DONE)

            These functions can be computed directly. In order to do this we must:
            # Sort the rows.
            # Detect partition boundaries (on the fly as well)
            # Given partition boundaries, compute the corresponding function value, for each row.

            Two-pass window functions:
            * -percent_rank (test implementation needs review)-
            * -cume_dist (see MDEV-9746)-
            * -ntile-
            * -nth_value (this is frame-based)- (DONE)
            * -last_value (this is frame-based)- (DONE)
            these require two passes over partition to compute. The extra information that we require is the number of rows in the partition. In order to find the number of rows, we must first detect partition boundaries and then we can compute the number of rows per partition.

            Two-cursor window functions:
            * -lag- (DONE)
            * -lead- (DONE)
            these require an additional cursor that is traveling n rows ahead/behind the current_row cursor.

            Key pieces for implementing this:
            * Make use of the filesort interface, since we do not need temporary tables for these functions.
            * It is a very similar use case to the GROUP BY statement. An important task is figuring out partition boundaries. The classes used for computing GROUP BY, might prove useful.
            serg Sergei Golubchik made changes -
            Workflow MariaDB v3 [ 64832 ] MariaDB v4 [ 132604 ]

            People

              cvicentiu Vicențiu Ciorbaru
              cvicentiu Vicențiu Ciorbaru
              Votes:
              9 Vote for this issue
              Watchers:
              14 Start watching this issue

              Dates

                Created:
                Updated:
                Resolved:

                Git Integration

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