+1Running below, where both b and p are rather complex, but individually each are quite fast, however running UNION ALL is very slow:
This seems to be a well known issue with sql in general, for example:
https://stackoverflow.com/questions/44055834/simple-sql-union-all-very-slow
https://stackoverflow.com/questions/38373206/multiple-union-alls-unbearably-slow
Wonder what would be Vertica's solution? Thanks
+2@BHIFP Is it possible to rewrite the query, or rewrite the logic calling the query?
We've improved the performance of Common Table Expressions with temp relations so I wonder if the query could be written with "b" and "p" as materialized sub-queries in a WITH clause.
Alternately, if the individual queries run quickly, it might be possible to create a temp table to hold the results of the individual queries then select from the temp table. The caller would have to implement that or use a stored procedure to generate the temp result set.
This would be a good question for engineering at Unify coming up next week in Boston or later in the month in Paris.
+2Try to trigger merge join, it is possible, there is a special hint.
You do not need merge join here, but it has advantage that both rowsources will be run in parallel and consumed in parallel by UNION ALL operator. No need to materialise etc.
Already have an account? Login
Enter your E-mail address. We'll send you an e-mail with instructions to reset your password.
77 4th Avenue
Waltham, MA 02451 USA
