babelfish-for-postgresql / babelfish_extensions / 13454356773

76%

BABEL_5_X_DEV: 77%

push

github

Fix parallel query execution for TSQL statements post community commit <a class=hub.com/babelfish-for-postgresql/babelfish_extensions/commit/7f07ff583ea8d55bb32853de40c3a9b69644c80f">7f07ff583 (#3518)

Community commit 7f07ff583ea8d55bb32853de40c3a9b69644c80f simplified executor code to decide whether to use
parallel query. Based on the new condition executor will never pick parallel operation if numberTuples != 0 is non zero,
which happens when we put a limit on number of tuples that can be returned by executor.

In Babelfish we were always initializing the rowcount as INT_MAX and the setting numberTuples = rowcount, which
means babelfish select query will never be able to use parallelism even though it could.

The correct default value for row count should always have been zero meaning no LIMIT.

Even with this patch, queries will not use parallel query when row count is set to a non zero value by user.

A very simple example with & without this patch
'''
SELECT * INTO t FROM generate_series(1,10000000)
GO
SELECT COUNT(*) FROM t
GO

-- With patch
SELECT COUNT(*) FROM t
Clock Time (ms.): total       526  avg   526.0 (1.9 xacts per sec.)

-- Without patch
SELECT COUNT(*) FROM t
Clock Time (ms.): total      1427  avg   1427.0 (0.7 xacts per sec.)
'''

Signed-off-by: Tanzeel Khan <tzlkhan@amazon.com>

47103 of 62806 relevant lines covered (75.0%)

186496.2 hits per line