fallback発生するNATURAL JOINの結果がCPU実行時と異なる

[0-kaz]

SET pg_strom.regression_test_mode = on;

CREATE EXTENSION IF NOT EXISTS pg_strom;

-- disables SeqScan and kernel source
SET enable_seqscan = off;

-- prepare table
-- test for CPU fallback / GPU kernel suspend/resume
DROP TABLE IF EXISTS fallback_data;
CREATE TABLE fallback_data (
  id    int,
  aid   int,
  cat   text,
  x     float,
  y     float,
  memo  text
);
INSERT INTO fallback_data (
  SELECT x, pgstrom.random_int(0.5, 1, 4000),
            CASE floor(random()*26)
            WHEN 0 THEN 'aaa'
            WHEN  1 THEN 'bbb'
            WHEN  2 THEN 'ccc'
            WHEN  3 THEN 'ddd'
            WHEN  4 THEN 'eee'
            WHEN  5 THEN 'fff'
            WHEN  6 THEN 'ggg'
            WHEN  7 THEN 'hhh'
            WHEN  8 THEN 'iii'
            WHEN  9 THEN 'jjj'
            WHEN 10 THEN 'kkk'
            WHEN 11 THEN 'lll'
            WHEN 12 THEN 'mmm'
            WHEN 13 THEN 'nnn'
            WHEN 14 THEN 'ooo'
            WHEN 15 THEN 'ppp'
            WHEN 16 THEN 'qqq'
            WHEN 17 THEN 'rrr'
            WHEN 18 THEN 'sss'
            WHEN 19 THEN 'ttt'
            WHEN 20 THEN 'uuu'
            WHEN 21 THEN 'vvv'
            WHEN 22 THEN 'www'
            WHEN 23 THEN 'xxx'
            WHEN 24 THEN 'yyy'
            ELSE 'zzz'
            END,
            pgstrom.random_float(2,-1000.0,1000.0),
            pgstrom.random_float(2,-1000.0,1000.0),
            pgstrom.random_text_len(2, 200)
    FROM generate_series(1,400001) x);

UPDATE fallback_data
   SET memo = md5(memo) || md5(memo)
 WHERE id = 400001;
UPDATE fallback_data
   SET memo = memo || '-' || memo || '-' || memo || '-' || memo
 WHERE id = 400001;
UPDATE fallback_data
   SET memo = memo || '-' || memo || '-' || memo || '-' || memo
 WHERE id = 400001;
UPDATE fallback_data
   SET memo = memo || '-' || memo || '-' || memo || '-' || memo
 WHERE id = 400001;
DROP TABLE IF EXISTS fallback_enlarge;
CREATE TABLE fallback_enlarge (
  aid   int,
  z     float,
  md5   char(200)
);
INSERT INTO fallback_enlarge (
  SELECT x / 5, pgstrom.random_float(2,-1000.0,1000.0),
            md5(x::text)
    FROM generate_series(1,20000) x);

DROP TABLE IF EXISTS test12p;
DROP TABLE IF EXISTS test12g;
SET pg_strom.enabled = on;
SELECT * INTO test12g
  FROM fallback_data d NATURAL JOIN fallback_enlarge l
 WHERE l.aid < 2500 AND memo like '%ab%';
SET pg_strom.enabled = off;
SELECT * INTO test12p
  FROM fallback_data d NATURAL JOIN fallback_enlarge l
 WHERE l.aid < 2500 AND memo like '%ab%';
-- 以下の結果は0行であることが期待される。以下の結果は0行だが・・・
(SELECT * FROM test12g EXCEPT SELECT * FROM test12p) ORDER BY id;
-- 以下の行は結果が出力されてしまう＝NATURAL JOINの結果が不一致になっている。
(SELECT * FROM test12p EXCEPT SELECT * FROM test12g) ORDER BY id;

[0-kaz]

PG15でも発生することを確認。

[kaigai]

hoge=# select * from test12g where memo = 'WyFqoCL42iYmn3ZrXM7F74hfSDHg0dNabq6RzrbB7gNd5zt3Pi8qOgRhQG2Ki4KHAOGCREvqjI4/';
 aid  |   id   | cat |         x         |         y         |                                     memo                                     |         z          |               md5
------+--------+-----+-------------------+-------------------+------------------------------------------------------------------------------+--------------------+----------------------------------
 2047 | 179247 | bbb | 419.8411067108816 | 276.0799672808871 | WyFqoCL42iYmn3ZrXM7F74hfSDHg0dNabq6RzrbB7gNd5zt3Pi8qOgRhQG2Ki4KHAOGCREvqjI4/ |  518.9477007458675 | d87d3902e1c4efdc9d79e94c4921bb40
 2047 | 179247 | bbb | 419.8411067108816 | 276.0799672808871 | WyFqoCL42iYmn3ZrXM7F74hfSDHg0dNabq6RzrbB7gNd5zt3Pi8qOgRhQG2Ki4KHAOGCREvqjI4/ | -840.0900214165869 | 0b32f1a9efe5edf3dd2f38b0c0052bfe
 2047 | 179247 | bbb | 419.8411067108816 | 276.0799672808871 | WyFqoCL42iYmn3ZrXM7F74hfSDHg0dNabq6RzrbB7gNd5zt3Pi8qOgRhQG2Ki4KHAOGCREvqjI4/ |  -585.981242165892 | c589c3a8f99401b24b9380e86d939842
 2047 | 179247 | bbb | 419.8411067108816 | 276.0799672808871 | WyFqoCL42iYmn3ZrXM7F74hfSDHg0dNabq6RzrbB7gNd5zt3Pi8qOgRhQG2Ki4KHAOGCREvqjI4/ | 115.48537906049069 | db261d4f615f0e982983be499e57ccda
 2047 | 179247 | bbb | 419.8411067108816 | 276.0799672808871 | WyFqoCL42iYmn3ZrXM7F74hfSDHg0dNabq6RzrbB7gNd5zt3Pi8qOgRhQG2Ki4KHAOGCREvqjI4/ |  455.0818481739061 | 1e9491470749d5b0e361ce4f0b24d037
(5 rows)

hoge=# select * from test12p where memo = 'WyFqoCL42iYmn3ZrXM7F74hfSDHg0dNabq6RzrbB7gNd5zt3Pi8qOgRhQG2Ki4KHAOGCREvqjI4/';
 aid  |   id   | cat |         x         |         y         |                                     memo                                     |         z          |                                                                                                   md5

------+--------+-----+-------------------+-------------------+------------------------------------------------------------------------------+--------------------+----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
 2047 | 179247 | bbb | 419.8411067108816 | 276.0799672808871 | WyFqoCL42iYmn3ZrXM7F74hfSDHg0dNabq6RzrbB7gNd5zt3Pi8qOgRhQG2Ki4KHAOGCREvqjI4/ |  518.9477007458675 | d87d3902e1c4efdc9d79e94c4921bb40
 2047 | 179247 | bbb | 419.8411067108816 | 276.0799672808871 | WyFqoCL42iYmn3ZrXM7F74hfSDHg0dNabq6RzrbB7gNd5zt3Pi8qOgRhQG2Ki4KHAOGCREvqjI4/ | -840.0900214165869 | 0b32f1a9efe5edf3dd2f38b0c0052bfe
 2047 | 179247 | bbb | 419.8411067108816 | 276.0799672808871 | WyFqoCL42iYmn3ZrXM7F74hfSDHg0dNabq6RzrbB7gNd5zt3Pi8qOgRhQG2Ki4KHAOGCREvqjI4/ |  -585.981242165892 | c589c3a8f99401b24b9380e86d939842
 2047 | 179247 | bbb | 419.8411067108816 | 276.0799672808871 | WyFqoCL42iYmn3ZrXM7F74hfSDHg0dNabq6RzrbB7gNd5zt3Pi8qOgRhQG2Ki4KHAOGCREvqjI4/ | 115.48537906049069 | db261d4f615f0e982983be499e57ccda
 2047 | 179247 | bbb | 419.8411067108816 | 276.0799672808871 | WyFqoCL42iYmn3ZrXM7F74hfSDHg0dNabq6RzrbB7gNd5zt3Pi8qOgRhQG2Ki4KHAOGCREvqjI4/ |  455.0818481739061 | 1e9491470749d5b0e361ce4f0b24d037
(5 rows)

なんだか、こんな風になってますね。 char(200)であるmd5の後ろは空白のパディングが必要なのですが、GPUでProjectionしたデータに関しては付いていません。 （でも文字列比較などでは、末尾の空白は除去して処理するので、あまり意味のないデータではあります）

ちょっと修正方法を考えてみますね。

[kaigai]

e9b228b4d38283baa098e572a23475935dab0bcb でサクッと直してみました。 CPU fallbackではなく、bpchar型のwrite_datumハンドラで末尾の空白パディングを入れるようにしています。

[kaigai]

たぶんこれ、numericで桁数がCPUの時と合わない問題も同様に対処できる気が・・・。

[0-kaz]

確認したのですが、解消確認出来ませんでした。不一致の要因引き続き確認しています。

[0-kaz]

NATURAL JOIN実行の前にを入れてmd5の列を空にしても不一致が生じているので、どうやらmd5の結果の不一致が原因ではないのかもしれません。

UPDATE fallback_enlarge SET md5 = '';

[0-kaz]

NATURAL JOINの条件からmemo LIKE '%ab%'を取り除くと本現象発生しませんでした。

DROP TABLE IF EXISTS test12p;
DROP TABLE IF EXISTS test12g;
SET pg_strom.enabled = on;
SELECT * INTO test12g
  FROM fallback_data d NATURAL JOIN fallback_enlarge l
 WHERE l.aid < 2500;
SET pg_strom.enabled = off;
SELECT * INTO test12p
  FROM fallback_data d NATURAL JOIN fallback_enlarge l
 WHERE l.aid < 2500;

[kaigai]

ちょっと最新版で試してもらえますか？

747 の絡みでCPU Fallback処理にパッチを当てているので、その過程で直っているかもです。

（なお海外の環境では再現させられませんでした）

[0-kaz]

6ee93d6dff13036ac5e37ce38542f7586e02320d では再現しないことを確認しました。