(JP) boolean型をtext型にキャストしたカラムをgroup byとorder byに指定すると、AssertionFailedとなる

[taiki-k]

boolean型のカラムをtext型にキャストし、そのカラムをgroup byとorder byに同時に指定したSQLを実行したところ、
Assertion Failedとなりました。

• バックトレース

#0  0x0000003cdbc32925 in raise () from /lib64/libc.so.6
#1  0x0000003cdbc34105 in abort () from /lib64/libc.so.6
#2  0x0000000000948a59 in ExceptionalCondition (conditionName=0x7f0bf4e51b30 "!(gsortstate->scan_done)",
    errorType=0x7f0bf4e510e4 "FailedAssertion", fileName=0x7f0bf4e5113f "gpusort.c", lineNumber=1856) at assert.c:54
#3  0x00007f0bf4e39b03 in gpusort_exec (node=0x16c3590) at gpusort.c:1856
#4  0x0000000000680dcb in ExecCustomPlan (cpstate=0x16c3590) at nodeCustom.c:37
#5  0x0000000000668ae5 in ExecProcNode (node=0x16c3590) at execProcnode.c:453
#6  0x000000000066652c in ExecutePlan (estate=0x16c3478, planstate=0x16c3590, operation=CMD_SELECT, sendTuples=1 '\001',
    numberTuples=0, direction=ForwardScanDirection, dest=0x16a8b50) at execMain.c:1475
#7  0x00000000006643dc in standard_ExecutorRun (queryDesc=0x161f758, direction=ForwardScanDirection, count=0) at execMain.c:308
#8  0x000000000066421f in ExecutorRun (queryDesc=0x161f758, direction=ForwardScanDirection, count=0) at execMain.c:256
#9  0x00000000007f9e7e in PortalRunSelect (portal=0x16d6408, forward=1 '\001', count=0, dest=0x16a8b50) at pquery.c:946
#10 0x00000000007f9aa5 in PortalRun (portal=0x16d6408, count=9223372036854775807, isTopLevel=1 '\001', dest=0x16a8b50,
    altdest=0x16a8b50, completionTag=0x7fffd1307930 "") at pquery.c:790
#11 0x00000000007f3212 in exec_simple_query (
    query_string=0x1665918 "select pass::text, count(*) from member_score_pass group by pass order by pass;") at postgres.c:1045
#12 0x00000000007f7992 in PostgresMain (argc=1, argv=0x15f6638, dbname=0x15f6498 "pgstrom_test", username=0x15f6478 "tkondo")
    at postgres.c:4004
#13 0x000000000076e8e9 in BackendRun (port=0x1621010) at postmaster.c:4117
#14 0x000000000076df9f in BackendStartup (port=0x1621010) at postmaster.c:3791
#15 0x000000000076a366 in ServerLoop () at postmaster.c:1570
#16 0x00000000007699b9 in PostmasterMain (argc=1, argv=0x15f5430) at postmaster.c:1223
#17 0x00000000006b9166 in main (argc=1, argv=0x15f5430) at main.c:227

• 実行したSQL

SELECT pass::text, count(*) FROM member_score_pass GROUP BY pass ORDER BY pass;

• 対象のテーブル

テーブル "public.member_score_pass"
    列     |   型    |  修飾語
-----------+---------+----------
 id        | integer | not null
 max_score | integer |
 pass      | boolean |
インデックス:
    "member_score_pass_pkey" PRIMARY KEY, btree (id)

• クエリープラン

                                            QUERY PLAN
---------------------------------------------------------------------------------------------------
 Custom (GpuSort)  (cost=30506.03..30506.03 rows=2 width=1)
   Sort keys: ((pass)::text)
   Sort keys width: 36
   Rows per chunk: 0
   ->  HashAggregate  (cost=30506.00..30506.03 rows=2 width=1)
         Group Key: pass
         ->  Custom (GpuScan) on member_score_pass  (cost=10000.00..25506.00 rows=1000000 width=1)
               Host References: pass
               Device References:
 Planning time: 0.431 ms

[kaigai]

これ、Rows per chunk: 0 になってますが、おそらく、bool型のように非常に同じ値の
重複が多いケースで、それを集約したので予測される結果の行数がとても少ない。

で、sorting-chunkを初期化する際に、最大で何行分のバッファを用意せねばならない
のかを予測するけれども、それを PGSTROM_WORKGROUP_UNITSZ (=32) で
切り落としていた。
行数が多い場合にはほとんど問題にはならないけれども、これが32より小さい場合には
0個分の容量の sorting-chunk を作ってしまい、結果、一個もデータが載らない。

そのため、スキャンが完了していないのに、gpusort_preload_subplan() が NULL を
返却して Assert() を踏んでしまう、となるようです。

pgstrom_test=# explain SELECT pass::text, count(*) FROM member_score_pass GROUP
BY pass ORDER BY pass;

QUERY PLAN

Custom (GpuSort) (cost=215052.91..215052.92 rows=2 width=1)
Sort keys: ((pass)::text)
Sort keys width: 36
Rows per chunk: 32
-> HashAggregate (cost=215052.89..215052.91 rows=2 width=1)
Group Key: pass
-> Custom (GpuScan) on member_score_pass (cost=10000.00..165053.59 ro
ws=9999860 width=1)
Host References: pass
Device References:
Planning time: 0.213 ms
(10 rows)

[taiki-k]

最新版で再現確認を行った結果、再現しなくなりました。
修正されたものと判断します。