Cool stuff! On 25/05/18 06:35, Andres Freund wrote:
For example, this converts this converts TPCH's Q01:tpch_1[26142][1]=# SET client_min_messages ='log'; tpch_1[26142][1]=# SELECT l_returnflag, l_linestatus, sum(l_quantity) AS sum_qty, sum(l_extendedprice) AS sum_base_price, sum(l_extendedprice * (1 - l_discount)) AS sum_disc_price, sum(l_extendedprice * (1 - l_discount) * (1 + l_tax)) AS sum_charge, avg(l_quantity) AS avg_qty, avg(l_extendedprice) AS avg_price, avg(l_discount) AS avg_disc, count(*) AS count_order FROM lineitem WHERE l_shipdate <= date '1998-12-01' - interval '74 days' GROUP BY l_returnflag, l_linestatus ORDER BY l_returnflag, l_linestatus; LOG: 00000: pp: into: 0: init_sort 1: seqscan_first 2: seqscan [j empty 5] > s0 3: qual [j fail 2] < scan s0 4: hashagg_tuple [j 2] < s0 5: drain_hashagg [j empty 7] > s1 6: sort_tuple [j 5] < s1 7: sort 8: drain_sort [j empty 10] > s2 9: return < s2 [next 8] 10: done where s are numbered slots, j are, potentially conditional, jumps. This works for a number of plans, but there's several where we currently bail out.
How is this going to look like in EXPLAIN, even without ANALYZE? Would it still show a tree plan, or this linear program, or both?
Despite being entirely unoptimized this already yields a measurable speedup over the current executor for the TPCH queries it supports.
Oh, that's impressive! - Heikki
