Presto-Performance-Tuning ROW_NUMBER 2019

ROW_NUMBERはパフォーマンスが悪いしメモリも多く使うから遅いのでRANKかDENSE_RANKを使えってことだけど0.201からROW_NUMBERのパフォーマンスかなり改善されてるっぽい。

ちょっと読み切れないとこあるけどSqlTopNRowNumberBenchmarkの結果を見てもRANKとROW_NUMBERであんまり遜色ないパフォーマンスになってる。

commit c2affb70afb5d236f011bed2fc6e5fab2dc43d47
Author: James Sun <jamessun@fb.com>
Date:   Thu Apr 26 19:12:02 2018 -0700

    Optimize TopNRowNumberOperator with GroupedTopNBuilder

    Use GroupedTopNBuilder to avoid copy of positions originally through
    getSingleValueBlock(), which causes huge GC pressue in production. Also,
    optimize the logic of flushing pages by lowering the complexity from
    quadratic to linear.

    SqlTopNRowNumberBenchmark results (in CPU ms):

    partition           top N      rank()      row_number()
                                            (after)  (before)
    (orderkey, partkey) 1      ::  181.703  190.381  1440.098
    (orderkey, partkey) 100    ::  164.800  169.391  36386.739
    (orderkey, partkey) 10000  ::  167.248  180.869  36477.663
    (partkey)           1      ::  242.923  309.629  379.481
    (partkey)           100    ::  305.621  305.903  415.921
    (partkey)           10000  ::  290.119  288.386  387.432
    (linestatus)        1      ::  199.527  303.186  249.250
    (linestatus)        100    ::  200.141  321.515  239.981
    (linestatus)        10000  ::  212.448  303.758  367.990
    (linestatus)        60000  ::  389.473  338.067  421.082

とはいえ0.201からの対応なのでそこは各自。