Skip to content

Conversation

@github-actions
Copy link
Contributor

Cherry-picked from #44164

…zed view (#44164)

Problem Summary:

When materialized view is rewritten, it would use the mv metadata.
Should try to get read lock before use these metadata. or it would cause
error.
Such as mv def is as following

CREATE MATERIALIZED VIEW mv1
        BUILD IMMEDIATE REFRESH COMPLETE ON MANUAL
        DISTRIBUTED BY RANDOM BUCKETS 2
        PROPERTIES ('replication_num' = '1') 
        AS
          select
              o_orderdate,
              o_shippriority,
              o_comment,
              o.o_code as o_o_code,
              l_orderkey, 
              l_partkey,
              l.o_code as l_o_code
            from
              orders_same_col o left
              join lineitem_same_col l on l_orderkey = o_orderkey
              left join partsupp on ps_partkey = l_partkey and l_suppkey = ps_suppkey;

When handling transparent rewriting, a MV scan plan is used for the
transparent rewrite. During the initialization of the scan plan, the
partitions of the table are retrieved, so it is necessary to attempt to
acquire a read lock on the table during initialization. If the read lock
is not acquired, subsequent operations may add or delete partitions, and
in the later processing of table partitions, calling get Partition may
not retrieve the corresponding partition, leading to data errors.
@doris-robot
Copy link

Thank you for your contribution to Apache Doris.
Don't know what should be done next? See How to process your PR.

Please clearly describe your PR:

  1. What problem was fixed (it's best to include specific error reporting information). How it was fixed.
  2. Which behaviors were modified. What was the previous behavior, what is it now, why was it modified, and what possible impacts might there be.
  3. What features were added. Why was this function added?
  4. Which code was refactored and why was this part of the code refactored?
  5. Which functions were optimized and what is the difference before and after the optimization?

@dataroaring dataroaring reopened this Nov 19, 2024
@doris-robot
Copy link

run buildall

@doris-robot
Copy link

TPC-H: Total hot run time: 43191 ms
machine: 'aliyun_ecs.c7a.8xlarge_32C64G'
scripts: https://github.com/apache/doris/tree/master/tools/tpch-tools
Tpch sf100 test result on commit d5dbe1f0c4cfd235bfd73efa6b65fe8bdda0370c, data reload: false

------ Round 1 ----------------------------------
q1	17887	7773	7315	7315
q2	2045	166	154	154
q3	10706	1141	1165	1141
q4	10469	770	747	747
q5	7722	2855	2793	2793
q6	234	149	147	147
q7	989	610	608	608
q8	9364	1927	1992	1927
q9	6608	6418	6388	6388
q10	7025	2297	2280	2280
q11	459	254	254	254
q12	396	217	204	204
q13	17907	2968	2968	2968
q14	240	212	201	201
q15	565	507	528	507
q16	696	594	579	579
q17	972	557	531	531
q18	7416	6590	6657	6590
q19	2101	1010	1053	1010
q20	2853	2665	2664	2664
q21	3927	3241	3199	3199
q22	1097	1018	984	984
Total cold run time: 111678 ms
Total hot run time: 43191 ms

----- Round 2, with runtime_filter_mode=off -----
q1	7295	7225	7292	7225
q2	315	224	217	217
q3	2840	2720	2697	2697
q4	1896	1625	1740	1625
q5	5369	5416	5410	5410
q6	214	135	133	133
q7	2043	1631	1651	1631
q8	3230	3384	3375	3375
q9	8523	8550	8441	8441
q10	3447	3394	3367	3367
q11	584	489	483	483
q12	738	549	560	549
q13	16906	2977	2973	2973
q14	301	261	256	256
q15	545	503	499	499
q16	683	649	643	643
q17	1811	1585	1554	1554
q18	7705	7386	7285	7285
q19	1641	1594	1533	1533
q20	1979	1796	1773	1773
q21	5089	5038	4822	4822
q22	1080	998	994	994
Total cold run time: 74234 ms
Total hot run time: 57485 ms

@morrySnow
Copy link
Contributor

run external

@morrySnow morrySnow closed this Nov 22, 2024
@dataroaring dataroaring deleted the auto-pick-44164-branch-3.0 branch December 27, 2024 07:07
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

5 participants