Skip to content

Conversation

@suxiaogang223
Copy link
Contributor

@suxiaogang223 suxiaogang223 commented Apr 17, 2025

What problem does this PR solve?

Related PR: #18615

Problem Summary:
The problem is like apache/doris-thirdparty#256
When performing late materialization for LIST or MAP types, filters should not be applied directly to their child fields. These complex types rely on offsets to correctly map parent-child relationships within the columnar storage layout (e.g., in ORC or Parquet files).

If filters are applied to the children of a LIST or MAP field, it may cause inconsistencies in the offset alignment, leading to incorrect data being read—such as mismatched elements, missing values, or even runtime errors. This breaks the structural integrity of the nested data and can produce incorrect query results.

mysql> select * from complex_data_orc;
+------+--------------------------+-----------------+
| id   | m                        | l               |
+------+--------------------------+-----------------+
|    1 | {"a":1, "b":2}           | ["a", "b"]      |
|    2 | {"b":3, "c":4}           | ["b"]           |
|    3 | {"c":5, "a":6, "b":7}    | ["c", "a"]      |
|    4 | {"a":8, "c":9}           | ["b", "c"]      |
|    5 | {"b":10, "a":11}         | ["a"]           |
|    6 | {"c":12, "b":13}         | ["c"]           |
|    7 | {"a":15}                 | ["a", "a"]      |
|    8 | {"b":17}                 | ["b", "b"]      |
|    9 | {"c":19}                 | ["c", "c"]      |
|   10 | {"a":20, "b":21, "c":22} | ["a", "b", "c"] |
+------+--------------------------+-----------------+
10 rows in set (0.02 sec)

!!!WRONG RESULT:
mysql> select * from complex_data_orc where id > 2;
+------+--------------------------+----------------+
| id   | m                        | l              |
+------+--------------------------+----------------+
|    3 | {"c":5, "a":6, "b":7}    | ["c", "a"]     |
|    4 | {"a":8, "c":9}           | ["b", "c"]     |
|    5 | {"b":10, "":11}          | ["a"]          |
|    6 | {"":12, "":13}           | ["c"]          |
|    7 | {"":15}                  | ["a", ""]      |
|    8 | {"":17}                  | ["", ""]       |
|    9 | {"":19}                  | ["", ""]       |
|   10 | {"a":20, "b":21, "c":22} | ["", "b", "c"] |
+------+--------------------------+----------------+
8 rows in set (0.02 sec)

To ensure correctness, filters should only be applied at the top level of the LIST or MAP, and their children should be read in full when late materialization occurs.

After this pr:

mysql> select * from complex_data_orc where id > 2;
+------+--------------------------+-----------------+
| id   | m                        | l               |
+------+--------------------------+-----------------+
|    3 | {"c":5, "a":6, "b":7}    | ["c", "a"]      |
|    4 | {"a":8, "c":9}           | ["b", "c"]      |
|    5 | {"b":10, "a":11}         | ["a"]           |
|    6 | {"c":12, "b":13}         | ["c"]           |
|    7 | {"a":15}                 | ["a", "a"]      |
|    8 | {"b":17}                 | ["b", "b"]      |
|    9 | {"c":19}                 | ["c", "c"]      |
|   10 | {"a":20, "b":21, "c":22} | ["a", "b", "c"] |
+------+--------------------------+-----------------+
8 rows in set (1.41 sec)

Release note

None

Check List (For Author)

  • Test

    • Regression test
    • Unit Test
    • Manual test (add detailed scripts or steps below)
    • No need to test or manual test. Explain why:
      • This is a refactor/code format and no logic has been changed.
      • Previous test can cover this change.
      • No code files have been changed.
      • Other reason
  • Behavior changed:

    • No.
    • Yes.
  • Does this need documentation?

    • No.
    • Yes.

Check List (For Reviewer who merge this PR)

  • Confirm the release note
  • Confirm test cases
  • Confirm document
  • Add branch pick label

@hello-stephen
Copy link
Contributor

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?

@suxiaogang223 suxiaogang223 changed the title [fix](orc) Should not pass selection vector when decode child column of ListColumn or MapColumn [fix](orc) Should not pass selection vector when decode child column of ListColumn Apr 17, 2025
@suxiaogang223 suxiaogang223 changed the title [fix](orc) Should not pass selection vector when decode child column of ListColumn [fix](orc) Should not pass selection vector when decode child column of List o r Map Apr 17, 2025
@suxiaogang223
Copy link
Contributor Author

run buildall

@suxiaogang223 suxiaogang223 changed the title [fix](orc) Should not pass selection vector when decode child column of List o r Map [fix](orc) Should not pass selection vector when decode child column of List or Map Apr 17, 2025
@doris-robot
Copy link

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

------ Round 1 ----------------------------------
q1	25869	5300	5034	5034
q2	2083	288	187	187
q3	10383	1213	690	690
q4	10225	998	539	539
q5	7521	2294	2319	2294
q6	185	163	130	130
q7	902	754	599	599
q8	9310	1236	1100	1100
q9	6780	5054	5116	5054
q10	6821	2296	1875	1875
q11	471	284	261	261
q12	351	350	226	226
q13	17769	3673	3113	3113
q14	223	220	203	203
q15	534	499	499	499
q16	447	442	402	402
q17	575	819	377	377
q18	7500	7133	7327	7133
q19	1564	975	569	569
q20	332	344	226	226
q21	4204	3396	2465	2465
q22	1013	1015	989	989
Total cold run time: 115062 ms
Total hot run time: 33965 ms

----- Round 2, with runtime_filter_mode=off -----
q1	5537	5005	5025	5005
q2	233	328	224	224
q3	2156	2623	2259	2259
q4	1436	1787	1389	1389
q5	4433	4333	4373	4333
q6	214	168	125	125
q7	2004	1894	1768	1768
q8	2596	2486	2493	2486
q9	7210	7173	6923	6923
q10	2995	3188	2756	2756
q11	571	528	500	500
q12	657	771	641	641
q13	3524	3847	3267	3267
q14	289	318	299	299
q15	526	488	471	471
q16	473	495	469	469
q17	1128	1497	1388	1388
q18	7753	7589	7380	7380
q19	809	820	851	820
q20	2023	1975	1813	1813
q21	5180	4789	4661	4661
q22	1088	1075	1041	1041
Total cold run time: 52835 ms
Total hot run time: 50018 ms

@doris-robot
Copy link

TPC-DS: Total hot run time: 191565 ms
machine: 'aliyun_ecs.c7a.8xlarge_32C64G'
scripts: https://github.com/apache/doris/tree/master/tools/tpcds-tools
TPC-DS sf100 test result on commit 900ee3588a5a3c8a3c0f6ed146b4196731434f5f, data reload: false

query1	1411	1094	1061	1061
query2	6308	1894	1830	1830
query3	11096	4616	4380	4380
query4	55670	25684	22919	22919
query5	5065	525	453	453
query6	353	192	183	183
query7	4929	490	293	293
query8	325	245	228	228
query9	6088	2558	2579	2558
query10	455	316	261	261
query11	15118	14947	14827	14827
query12	156	113	116	113
query13	1075	510	380	380
query14	10043	6264	6321	6264
query15	197	221	178	178
query16	7097	649	488	488
query17	1070	739	576	576
query18	1533	397	308	308
query19	200	181	168	168
query20	128	123	116	116
query21	205	153	106	106
query22	4380	4314	4275	4275
query23	33741	33144	33247	33144
query24	6648	2417	2398	2398
query25	474	473	400	400
query26	668	277	155	155
query27	2289	510	345	345
query28	3124	2169	2161	2161
query29	647	596	451	451
query30	283	233	205	205
query31	899	869	793	793
query32	78	66	68	66
query33	460	389	310	310
query34	782	879	555	555
query35	810	841	766	766
query36	957	1009	919	919
query37	124	105	75	75
query38	4133	4287	4156	4156
query39	1487	1442	1478	1442
query40	235	123	117	117
query41	60	56	60	56
query42	131	119	110	110
query43	515	552	505	505
query44	1360	820	811	811
query45	182	181	164	164
query46	851	1015	642	642
query47	1837	1863	1813	1813
query48	383	432	307	307
query49	702	509	435	435
query50	685	693	411	411
query51	4263	4305	4193	4193
query52	108	106	99	99
query53	226	264	181	181
query54	573	589	537	537
query55	88	81	110	81
query56	336	316	304	304
query57	1194	1178	1111	1111
query58	256	277	259	259
query59	2756	2829	2687	2687
query60	328	317	293	293
query61	129	126	128	126
query62	733	745	670	670
query63	235	187	189	187
query64	1464	1061	754	754
query65	4421	4380	4249	4249
query66	729	437	292	292
query67	15794	15329	15425	15329
query68	6870	835	505	505
query69	535	302	259	259
query70	1211	1142	1114	1114
query71	468	309	292	292
query72	6024	4802	4975	4802
query73	1237	679	349	349
query74	8877	9024	8821	8821
query75	3431	3182	2686	2686
query76	3976	1188	769	769
query77	626	374	271	271
query78	9998	10171	9244	9244
query79	2516	806	571	571
query80	689	501	432	432
query81	473	258	212	212
query82	437	124	99	99
query83	255	244	233	233
query84	293	109	80	80
query85	765	359	311	311
query86	378	315	277	277
query87	4352	4432	4329	4329
query88	3232	2222	2236	2222
query89	397	305	282	282
query90	1710	205	211	205
query91	147	138	114	114
query92	73	58	54	54
query93	2212	925	570	570
query94	723	413	294	294
query95	372	287	284	284
query96	484	574	273	273
query97	3175	3209	3113	3113
query98	221	203	196	196
query99	1418	1382	1273	1273
Total cold run time: 298655 ms
Total hot run time: 191565 ms

@doris-robot
Copy link

ClickBench: Total hot run time: 30.25 s
machine: 'aliyun_ecs.c7a.8xlarge_32C64G'
scripts: https://github.com/apache/doris/tree/master/tools/clickbench-tools
ClickBench test result on commit 900ee3588a5a3c8a3c0f6ed146b4196731434f5f, data reload: false

query1	0.04	0.03	0.03
query2	0.13	0.10	0.11
query3	0.26	0.19	0.19
query4	1.60	0.20	0.20
query5	0.58	0.58	0.57
query6	1.18	0.71	0.72
query7	0.02	0.02	0.02
query8	0.04	0.03	0.03
query9	0.58	0.54	0.52
query10	0.59	0.58	0.56
query11	0.16	0.12	0.10
query12	0.15	0.11	0.11
query13	0.60	0.60	0.59
query14	1.14	1.21	1.22
query15	0.87	0.84	0.84
query16	0.38	0.38	0.38
query17	1.00	1.01	1.04
query18	0.21	0.20	0.20
query19	1.86	1.80	1.82
query20	0.02	0.01	0.01
query21	15.40	0.88	0.55
query22	0.78	1.04	0.97
query23	14.76	1.38	0.69
query24	7.13	1.21	1.04
query25	0.52	0.07	0.12
query26	0.65	0.16	0.14
query27	0.05	0.05	0.05
query28	10.17	0.91	0.43
query29	12.58	4.04	3.37
query30	0.26	0.10	0.07
query31	2.82	0.58	0.38
query32	3.23	0.55	0.46
query33	2.97	3.00	3.05
query34	15.80	5.09	4.50
query35	4.56	4.54	4.59
query36	0.66	0.49	0.48
query37	0.09	0.06	0.06
query38	0.04	0.04	0.03
query39	0.03	0.03	0.03
query40	0.16	0.14	0.13
query41	0.07	0.03	0.03
query42	0.03	0.02	0.03
query43	0.03	0.04	0.03
Total cold run time: 104.2 s
Total hot run time: 30.25 s

@doris-robot
Copy link

BE UT Coverage Report

Increment line coverage 100.00% (7/7) 🎉

Increment coverage report
Complete coverage report

Category Coverage
Function Coverage 53.15% (14422/27132)
Line Coverage 42.02% (124986/297450)
Region Coverage 40.83% (63844/156379)
Branch Coverage 35.46% (32104/90534)

@suxiaogang223 suxiaogang223 force-pushed the fix_orc_list_map_lazy_mat branch from 900ee35 to c69fee9 Compare April 18, 2025 02:37
@suxiaogang223
Copy link
Contributor Author

run buildall

@github-actions github-actions bot added the approved Indicates a PR has been approved by one committer. label Apr 18, 2025
@github-actions
Copy link
Contributor

PR approved by at least one committer and no changes requested.

@github-actions
Copy link
Contributor

PR approved by anyone and no changes requested.

@doris-robot
Copy link

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

------ Round 1 ----------------------------------
q1	26471	5124	5007	5007
q2	2071	294	193	193
q3	10525	1255	699	699
q4	10228	1008	560	560
q5	7752	2392	2378	2378
q6	178	163	130	130
q7	909	745	615	615
q8	9305	1294	1137	1137
q9	6904	5090	5031	5031
q10	6812	2293	1883	1883
q11	484	279	274	274
q12	362	349	218	218
q13	17792	3657	3129	3129
q14	226	233	210	210
q15	529	484	485	484
q16	453	452	407	407
q17	608	856	365	365
q18	7672	7301	7154	7154
q19	1832	956	575	575
q20	327	326	222	222
q21	3947	2653	2423	2423
q22	1048	1015	977	977
Total cold run time: 116435 ms
Total hot run time: 34071 ms

----- Round 2, with runtime_filter_mode=off -----
q1	5200	5080	5251	5080
q2	243	332	230	230
q3	2164	2702	2267	2267
q4	1457	1847	1482	1482
q5	4443	4386	4407	4386
q6	240	166	131	131
q7	1993	1916	1749	1749
q8	2596	2655	2556	2556
q9	7328	7192	6980	6980
q10	3039	3220	2735	2735
q11	580	505	491	491
q12	678	762	617	617
q13	3496	3871	3374	3374
q14	297	324	297	297
q15	539	481	481	481
q16	457	499	466	466
q17	1174	1531	1409	1409
q18	7726	7600	7459	7459
q19	821	879	996	879
q20	1999	1985	1827	1827
q21	5208	4883	4829	4829
q22	1142	1094	1018	1018
Total cold run time: 52820 ms
Total hot run time: 50743 ms

@doris-robot
Copy link

TPC-DS: Total hot run time: 191562 ms
machine: 'aliyun_ecs.c7a.8xlarge_32C64G'
scripts: https://github.com/apache/doris/tree/master/tools/tpcds-tools
TPC-DS sf100 test result on commit c69fee95a21dc1b2459480eb9678d3ce3cbfff47, data reload: false

query1	1425	1079	1069	1069
query2	6467	1743	1786	1743
query3	11176	4515	4632	4515
query4	53992	25420	23046	23046
query5	5302	485	433	433
query6	366	212	183	183
query7	5080	486	284	284
query8	316	274	222	222
query9	6736	2500	2535	2500
query10	436	303	260	260
query11	15109	15287	14786	14786
query12	156	110	106	106
query13	1165	504	393	393
query14	10079	6230	6259	6230
query15	202	198	191	191
query16	7075	664	486	486
query17	1090	735	574	574
query18	1516	400	311	311
query19	193	188	160	160
query20	131	133	116	116
query21	206	131	133	131
query22	4386	4435	4260	4260
query23	34269	33469	33494	33469
query24	6635	2404	2430	2404
query25	468	471	407	407
query26	673	275	157	157
query27	2297	502	331	331
query28	3067	2118	2095	2095
query29	580	547	417	417
query30	269	218	186	186
query31	880	893	782	782
query32	77	61	70	61
query33	465	387	330	330
query34	752	879	518	518
query35	825	840	793	793
query36	950	1000	917	917
query37	118	102	76	76
query38	4162	4226	4053	4053
query39	1502	1410	1418	1410
query40	209	118	107	107
query41	52	51	53	51
query42	123	111	110	110
query43	491	503	491	491
query44	1317	807	817	807
query45	185	175	173	173
query46	850	1021	630	630
query47	1804	1893	1785	1785
query48	400	400	299	299
query49	692	506	445	445
query50	669	691	395	395
query51	4245	4270	4228	4228
query52	106	109	99	99
query53	232	259	179	179
query54	568	576	501	501
query55	83	81	81	81
query56	301	319	299	299
query57	1165	1159	1123	1123
query58	256	263	269	263
query59	2716	2800	2636	2636
query60	324	321	347	321
query61	151	123	128	123
query62	753	721	689	689
query63	224	187	181	181
query64	1456	1047	700	700
query65	4479	4309	4264	4264
query66	711	401	300	300
query67	15545	15499	15374	15374
query68	4812	885	520	520
query69	506	311	255	255
query70	1210	1086	1116	1086
query71	421	322	294	294
query72	5915	4959	5024	4959
query73	789	699	354	354
query74	9061	9204	8722	8722
query75	3387	3229	2634	2634
query76	3570	1175	749	749
query77	528	376	284	284
query78	9955	10120	9206	9206
query79	2483	813	551	551
query80	646	490	435	435
query81	479	259	215	215
query82	436	127	96	96
query83	260	249	231	231
query84	288	97	88	88
query85	785	351	307	307
query86	423	309	296	296
query87	4346	4438	4320	4320
query88	3511	2208	2198	2198
query89	400	315	284	284
query90	1886	213	216	213
query91	137	139	109	109
query92	74	64	56	56
query93	2239	927	574	574
query94	648	414	306	306
query95	357	289	287	287
query96	491	557	268	268
query97	3128	3230	3139	3139
query98	224	201	206	201
query99	1317	1392	1266	1266
Total cold run time: 295412 ms
Total hot run time: 191562 ms

@doris-robot
Copy link

ClickBench: Total hot run time: 29.14 s
machine: 'aliyun_ecs.c7a.8xlarge_32C64G'
scripts: https://github.com/apache/doris/tree/master/tools/clickbench-tools
ClickBench test result on commit c69fee95a21dc1b2459480eb9678d3ce3cbfff47, data reload: false

query1	0.03	0.03	0.03
query2	0.12	0.10	0.12
query3	0.25	0.20	0.19
query4	1.58	0.20	0.20
query5	0.59	0.58	0.60
query6	1.19	0.71	0.72
query7	0.02	0.01	0.01
query8	0.04	0.03	0.03
query9	0.57	0.52	0.54
query10	0.56	0.57	0.56
query11	0.16	0.11	0.10
query12	0.14	0.11	0.11
query13	0.60	0.60	0.59
query14	1.18	1.20	1.17
query15	0.88	0.85	0.84
query16	0.41	0.37	0.37
query17	1.00	1.01	1.02
query18	0.21	0.19	0.19
query19	1.91	1.78	1.78
query20	0.01	0.01	0.02
query21	15.40	0.89	0.55
query22	0.77	1.24	0.70
query23	14.79	1.41	0.66
query24	6.91	0.92	0.28
query25	0.30	0.14	0.17
query26	0.67	0.16	0.13
query27	0.06	0.06	0.05
query28	9.26	0.93	0.44
query29	12.56	3.98	3.34
query30	0.26	0.09	0.07
query31	2.81	0.59	0.38
query32	3.22	0.55	0.46
query33	3.15	3.03	3.01
query34	15.71	5.13	4.51
query35	4.55	4.53	4.53
query36	0.68	0.49	0.48
query37	0.08	0.07	0.06
query38	0.06	0.04	0.04
query39	0.03	0.02	0.02
query40	0.16	0.14	0.12
query41	0.08	0.03	0.03
query42	0.04	0.02	0.03
query43	0.03	0.04	0.02
Total cold run time: 103.03 s
Total hot run time: 29.14 s

@hello-stephen
Copy link
Contributor

BE UT Coverage Report

Increment line coverage 100.00% (7/7) 🎉

Increment coverage report
Complete coverage report

Category Coverage
Function Coverage 53.15% (14422/27132)
Line Coverage 42.02% (124989/297455)
Region Coverage 40.83% (63844/156379)
Branch Coverage 35.47% (32109/90534)

Copy link
Contributor

@kaka11chen kaka11chen left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM

@morningman morningman merged commit 16c5374 into apache:master Apr 18, 2025
24 of 26 checks passed
suxiaogang223 added a commit to suxiaogang223/doris that referenced this pull request Apr 23, 2025
…of List or Map (apache#50136)

Related PR: apache#18615

Problem Summary:
The problem is like apache/doris-thirdparty#256
When performing late materialization for LIST or MAP types, filters
should not be applied directly to their child fields. These complex
types rely on offsets to correctly map parent-child relationships within
the columnar storage layout (e.g., in ORC or Parquet files).

If filters are applied to the children of a LIST or MAP field, it may
cause inconsistencies in the offset alignment, leading to incorrect data
being read—such as mismatched elements, missing values, or even runtime
errors. This breaks the structural integrity of the nested data and can
produce incorrect query results.

```text
mysql> select * from complex_data_orc;
+------+--------------------------+-----------------+
| id   | m                        | l               |
+------+--------------------------+-----------------+
|    1 | {"a":1, "b":2}           | ["a", "b"]      |
|    2 | {"b":3, "c":4}           | ["b"]           |
|    3 | {"c":5, "a":6, "b":7}    | ["c", "a"]      |
|    4 | {"a":8, "c":9}           | ["b", "c"]      |
|    5 | {"b":10, "a":11}         | ["a"]           |
|    6 | {"c":12, "b":13}         | ["c"]           |
|    7 | {"a":15}                 | ["a", "a"]      |
|    8 | {"b":17}                 | ["b", "b"]      |
|    9 | {"c":19}                 | ["c", "c"]      |
|   10 | {"a":20, "b":21, "c":22} | ["a", "b", "c"] |
+------+--------------------------+-----------------+
10 rows in set (0.02 sec)

!!!WRONG RESULT:
mysql> select * from complex_data_orc where id > 2;
+------+--------------------------+----------------+
| id   | m                        | l              |
+------+--------------------------+----------------+
|    3 | {"c":5, "a":6, "b":7}    | ["c", "a"]     |
|    4 | {"a":8, "c":9}           | ["b", "c"]     |
|    5 | {"b":10, "":11}          | ["a"]          |
|    6 | {"":12, "":13}           | ["c"]          |
|    7 | {"":15}                  | ["a", ""]      |
|    8 | {"":17}                  | ["", ""]       |
|    9 | {"":19}                  | ["", ""]       |
|   10 | {"a":20, "b":21, "c":22} | ["", "b", "c"] |
+------+--------------------------+----------------+
8 rows in set (0.02 sec)
```

To ensure correctness, filters should only be applied at the top level
of the LIST or MAP, and their children should be read in full when late
materialization occurs.

After this pr:
```text
mysql> select * from complex_data_orc where id > 2;
+------+--------------------------+-----------------+
| id   | m                        | l               |
+------+--------------------------+-----------------+
|    3 | {"c":5, "a":6, "b":7}    | ["c", "a"]      |
|    4 | {"a":8, "c":9}           | ["b", "c"]      |
|    5 | {"b":10, "a":11}         | ["a"]           |
|    6 | {"c":12, "b":13}         | ["c"]           |
|    7 | {"a":15}                 | ["a", "a"]      |
|    8 | {"b":17}                 | ["b", "b"]      |
|    9 | {"c":19}                 | ["c", "c"]      |
|   10 | {"a":20, "b":21, "c":22} | ["a", "b", "c"] |
+------+--------------------------+-----------------+
8 rows in set (1.41 sec)
```
suxiaogang223 added a commit to suxiaogang223/doris that referenced this pull request Apr 23, 2025
…of List or Map (apache#50136)

Related PR: apache#18615

Problem Summary:
The problem is like apache/doris-thirdparty#256
When performing late materialization for LIST or MAP types, filters
should not be applied directly to their child fields. These complex
types rely on offsets to correctly map parent-child relationships within
the columnar storage layout (e.g., in ORC or Parquet files).

If filters are applied to the children of a LIST or MAP field, it may
cause inconsistencies in the offset alignment, leading to incorrect data
being read—such as mismatched elements, missing values, or even runtime
errors. This breaks the structural integrity of the nested data and can
produce incorrect query results.

```text
mysql> select * from complex_data_orc;
+------+--------------------------+-----------------+
| id   | m                        | l               |
+------+--------------------------+-----------------+
|    1 | {"a":1, "b":2}           | ["a", "b"]      |
|    2 | {"b":3, "c":4}           | ["b"]           |
|    3 | {"c":5, "a":6, "b":7}    | ["c", "a"]      |
|    4 | {"a":8, "c":9}           | ["b", "c"]      |
|    5 | {"b":10, "a":11}         | ["a"]           |
|    6 | {"c":12, "b":13}         | ["c"]           |
|    7 | {"a":15}                 | ["a", "a"]      |
|    8 | {"b":17}                 | ["b", "b"]      |
|    9 | {"c":19}                 | ["c", "c"]      |
|   10 | {"a":20, "b":21, "c":22} | ["a", "b", "c"] |
+------+--------------------------+-----------------+
10 rows in set (0.02 sec)

!!!WRONG RESULT:
mysql> select * from complex_data_orc where id > 2;
+------+--------------------------+----------------+
| id   | m                        | l              |
+------+--------------------------+----------------+
|    3 | {"c":5, "a":6, "b":7}    | ["c", "a"]     |
|    4 | {"a":8, "c":9}           | ["b", "c"]     |
|    5 | {"b":10, "":11}          | ["a"]          |
|    6 | {"":12, "":13}           | ["c"]          |
|    7 | {"":15}                  | ["a", ""]      |
|    8 | {"":17}                  | ["", ""]       |
|    9 | {"":19}                  | ["", ""]       |
|   10 | {"a":20, "b":21, "c":22} | ["", "b", "c"] |
+------+--------------------------+----------------+
8 rows in set (0.02 sec)
```

To ensure correctness, filters should only be applied at the top level
of the LIST or MAP, and their children should be read in full when late
materialization occurs.

After this pr:
```text
mysql> select * from complex_data_orc where id > 2;
+------+--------------------------+-----------------+
| id   | m                        | l               |
+------+--------------------------+-----------------+
|    3 | {"c":5, "a":6, "b":7}    | ["c", "a"]      |
|    4 | {"a":8, "c":9}           | ["b", "c"]      |
|    5 | {"b":10, "a":11}         | ["a"]           |
|    6 | {"c":12, "b":13}         | ["c"]           |
|    7 | {"a":15}                 | ["a", "a"]      |
|    8 | {"b":17}                 | ["b", "b"]      |
|    9 | {"c":19}                 | ["c", "c"]      |
|   10 | {"a":20, "b":21, "c":22} | ["a", "b", "c"] |
+------+--------------------------+-----------------+
8 rows in set (1.41 sec)
```
suxiaogang223 added a commit to suxiaogang223/doris that referenced this pull request Apr 24, 2025
…of List or Map (apache#50136)

Related PR: apache#18615

Problem Summary:
The problem is like apache/doris-thirdparty#256
When performing late materialization for LIST or MAP types, filters
should not be applied directly to their child fields. These complex
types rely on offsets to correctly map parent-child relationships within
the columnar storage layout (e.g., in ORC or Parquet files).

If filters are applied to the children of a LIST or MAP field, it may
cause inconsistencies in the offset alignment, leading to incorrect data
being read—such as mismatched elements, missing values, or even runtime
errors. This breaks the structural integrity of the nested data and can
produce incorrect query results.

```text
mysql> select * from complex_data_orc;
+------+--------------------------+-----------------+
| id   | m                        | l               |
+------+--------------------------+-----------------+
|    1 | {"a":1, "b":2}           | ["a", "b"]      |
|    2 | {"b":3, "c":4}           | ["b"]           |
|    3 | {"c":5, "a":6, "b":7}    | ["c", "a"]      |
|    4 | {"a":8, "c":9}           | ["b", "c"]      |
|    5 | {"b":10, "a":11}         | ["a"]           |
|    6 | {"c":12, "b":13}         | ["c"]           |
|    7 | {"a":15}                 | ["a", "a"]      |
|    8 | {"b":17}                 | ["b", "b"]      |
|    9 | {"c":19}                 | ["c", "c"]      |
|   10 | {"a":20, "b":21, "c":22} | ["a", "b", "c"] |
+------+--------------------------+-----------------+
10 rows in set (0.02 sec)

!!!WRONG RESULT:
mysql> select * from complex_data_orc where id > 2;
+------+--------------------------+----------------+
| id   | m                        | l              |
+------+--------------------------+----------------+
|    3 | {"c":5, "a":6, "b":7}    | ["c", "a"]     |
|    4 | {"a":8, "c":9}           | ["b", "c"]     |
|    5 | {"b":10, "":11}          | ["a"]          |
|    6 | {"":12, "":13}           | ["c"]          |
|    7 | {"":15}                  | ["a", ""]      |
|    8 | {"":17}                  | ["", ""]       |
|    9 | {"":19}                  | ["", ""]       |
|   10 | {"a":20, "b":21, "c":22} | ["", "b", "c"] |
+------+--------------------------+----------------+
8 rows in set (0.02 sec)
```

To ensure correctness, filters should only be applied at the top level
of the LIST or MAP, and their children should be read in full when late
materialization occurs.

After this pr:
```text
mysql> select * from complex_data_orc where id > 2;
+------+--------------------------+-----------------+
| id   | m                        | l               |
+------+--------------------------+-----------------+
|    3 | {"c":5, "a":6, "b":7}    | ["c", "a"]      |
|    4 | {"a":8, "c":9}           | ["b", "c"]      |
|    5 | {"b":10, "a":11}         | ["a"]           |
|    6 | {"c":12, "b":13}         | ["c"]           |
|    7 | {"a":15}                 | ["a", "a"]      |
|    8 | {"b":17}                 | ["b", "b"]      |
|    9 | {"c":19}                 | ["c", "c"]      |
|   10 | {"a":20, "b":21, "c":22} | ["a", "b", "c"] |
+------+--------------------------+-----------------+
8 rows in set (1.41 sec)
```
suxiaogang223 added a commit to suxiaogang223/doris that referenced this pull request Apr 24, 2025
…of List or Map (apache#50136)

Related PR: apache#18615

Problem Summary:
The problem is like apache/doris-thirdparty#256
When performing late materialization for LIST or MAP types, filters
should not be applied directly to their child fields. These complex
types rely on offsets to correctly map parent-child relationships within
the columnar storage layout (e.g., in ORC or Parquet files).

If filters are applied to the children of a LIST or MAP field, it may
cause inconsistencies in the offset alignment, leading to incorrect data
being read—such as mismatched elements, missing values, or even runtime
errors. This breaks the structural integrity of the nested data and can
produce incorrect query results.

```text
mysql> select * from complex_data_orc;
+------+--------------------------+-----------------+
| id   | m                        | l               |
+------+--------------------------+-----------------+
|    1 | {"a":1, "b":2}           | ["a", "b"]      |
|    2 | {"b":3, "c":4}           | ["b"]           |
|    3 | {"c":5, "a":6, "b":7}    | ["c", "a"]      |
|    4 | {"a":8, "c":9}           | ["b", "c"]      |
|    5 | {"b":10, "a":11}         | ["a"]           |
|    6 | {"c":12, "b":13}         | ["c"]           |
|    7 | {"a":15}                 | ["a", "a"]      |
|    8 | {"b":17}                 | ["b", "b"]      |
|    9 | {"c":19}                 | ["c", "c"]      |
|   10 | {"a":20, "b":21, "c":22} | ["a", "b", "c"] |
+------+--------------------------+-----------------+
10 rows in set (0.02 sec)

!!!WRONG RESULT:
mysql> select * from complex_data_orc where id > 2;
+------+--------------------------+----------------+
| id   | m                        | l              |
+------+--------------------------+----------------+
|    3 | {"c":5, "a":6, "b":7}    | ["c", "a"]     |
|    4 | {"a":8, "c":9}           | ["b", "c"]     |
|    5 | {"b":10, "":11}          | ["a"]          |
|    6 | {"":12, "":13}           | ["c"]          |
|    7 | {"":15}                  | ["a", ""]      |
|    8 | {"":17}                  | ["", ""]       |
|    9 | {"":19}                  | ["", ""]       |
|   10 | {"a":20, "b":21, "c":22} | ["", "b", "c"] |
+------+--------------------------+----------------+
8 rows in set (0.02 sec)
```

To ensure correctness, filters should only be applied at the top level
of the LIST or MAP, and their children should be read in full when late
materialization occurs.

After this pr:
```text
mysql> select * from complex_data_orc where id > 2;
+------+--------------------------+-----------------+
| id   | m                        | l               |
+------+--------------------------+-----------------+
|    3 | {"c":5, "a":6, "b":7}    | ["c", "a"]      |
|    4 | {"a":8, "c":9}           | ["b", "c"]      |
|    5 | {"b":10, "a":11}         | ["a"]           |
|    6 | {"c":12, "b":13}         | ["c"]           |
|    7 | {"a":15}                 | ["a", "a"]      |
|    8 | {"b":17}                 | ["b", "b"]      |
|    9 | {"c":19}                 | ["c", "c"]      |
|   10 | {"a":20, "b":21, "c":22} | ["a", "b", "c"] |
+------+--------------------------+-----------------+
8 rows in set (1.41 sec)
```
suxiaogang223 added a commit to suxiaogang223/doris that referenced this pull request Apr 24, 2025
…of List or Map (apache#50136)

Related PR: apache#18615

Problem Summary:
The problem is like apache/doris-thirdparty#256
When performing late materialization for LIST or MAP types, filters
should not be applied directly to their child fields. These complex
types rely on offsets to correctly map parent-child relationships within
the columnar storage layout (e.g., in ORC or Parquet files).

If filters are applied to the children of a LIST or MAP field, it may
cause inconsistencies in the offset alignment, leading to incorrect data
being read—such as mismatched elements, missing values, or even runtime
errors. This breaks the structural integrity of the nested data and can
produce incorrect query results.

```text
mysql> select * from complex_data_orc;
+------+--------------------------+-----------------+
| id   | m                        | l               |
+------+--------------------------+-----------------+
|    1 | {"a":1, "b":2}           | ["a", "b"]      |
|    2 | {"b":3, "c":4}           | ["b"]           |
|    3 | {"c":5, "a":6, "b":7}    | ["c", "a"]      |
|    4 | {"a":8, "c":9}           | ["b", "c"]      |
|    5 | {"b":10, "a":11}         | ["a"]           |
|    6 | {"c":12, "b":13}         | ["c"]           |
|    7 | {"a":15}                 | ["a", "a"]      |
|    8 | {"b":17}                 | ["b", "b"]      |
|    9 | {"c":19}                 | ["c", "c"]      |
|   10 | {"a":20, "b":21, "c":22} | ["a", "b", "c"] |
+------+--------------------------+-----------------+
10 rows in set (0.02 sec)

!!!WRONG RESULT:
mysql> select * from complex_data_orc where id > 2;
+------+--------------------------+----------------+
| id   | m                        | l              |
+------+--------------------------+----------------+
|    3 | {"c":5, "a":6, "b":7}    | ["c", "a"]     |
|    4 | {"a":8, "c":9}           | ["b", "c"]     |
|    5 | {"b":10, "":11}          | ["a"]          |
|    6 | {"":12, "":13}           | ["c"]          |
|    7 | {"":15}                  | ["a", ""]      |
|    8 | {"":17}                  | ["", ""]       |
|    9 | {"":19}                  | ["", ""]       |
|   10 | {"a":20, "b":21, "c":22} | ["", "b", "c"] |
+------+--------------------------+----------------+
8 rows in set (0.02 sec)
```

To ensure correctness, filters should only be applied at the top level
of the LIST or MAP, and their children should be read in full when late
materialization occurs.

After this pr:
```text
mysql> select * from complex_data_orc where id > 2;
+------+--------------------------+-----------------+
| id   | m                        | l               |
+------+--------------------------+-----------------+
|    3 | {"c":5, "a":6, "b":7}    | ["c", "a"]      |
|    4 | {"a":8, "c":9}           | ["b", "c"]      |
|    5 | {"b":10, "a":11}         | ["a"]           |
|    6 | {"c":12, "b":13}         | ["c"]           |
|    7 | {"a":15}                 | ["a", "a"]      |
|    8 | {"b":17}                 | ["b", "b"]      |
|    9 | {"c":19}                 | ["c", "c"]      |
|   10 | {"a":20, "b":21, "c":22} | ["a", "b", "c"] |
+------+--------------------------+-----------------+
8 rows in set (1.41 sec)
```
yiguolei pushed a commit that referenced this pull request Apr 25, 2025
dataroaring pushed a commit that referenced this pull request Apr 25, 2025
@yiguolei yiguolei mentioned this pull request May 13, 2025
koarz pushed a commit to koarz/doris that referenced this pull request Jun 4, 2025
…of List or Map (apache#50136)

### What problem does this PR solve?
Related PR: apache#18615 

Problem Summary:
The problem is like apache/doris-thirdparty#256
When performing late materialization for LIST or MAP types, filters
should not be applied directly to their child fields. These complex
types rely on offsets to correctly map parent-child relationships within
the columnar storage layout (e.g., in ORC or Parquet files).

If filters are applied to the children of a LIST or MAP field, it may
cause inconsistencies in the offset alignment, leading to incorrect data
being read—such as mismatched elements, missing values, or even runtime
errors. This breaks the structural integrity of the nested data and can
produce incorrect query results.

```text
mysql> select * from complex_data_orc;
+------+--------------------------+-----------------+
| id   | m                        | l               |
+------+--------------------------+-----------------+
|    1 | {"a":1, "b":2}           | ["a", "b"]      |
|    2 | {"b":3, "c":4}           | ["b"]           |
|    3 | {"c":5, "a":6, "b":7}    | ["c", "a"]      |
|    4 | {"a":8, "c":9}           | ["b", "c"]      |
|    5 | {"b":10, "a":11}         | ["a"]           |
|    6 | {"c":12, "b":13}         | ["c"]           |
|    7 | {"a":15}                 | ["a", "a"]      |
|    8 | {"b":17}                 | ["b", "b"]      |
|    9 | {"c":19}                 | ["c", "c"]      |
|   10 | {"a":20, "b":21, "c":22} | ["a", "b", "c"] |
+------+--------------------------+-----------------+
10 rows in set (0.02 sec)

!!!WRONG RESULT:
mysql> select * from complex_data_orc where id > 2;
+------+--------------------------+----------------+
| id   | m                        | l              |
+------+--------------------------+----------------+
|    3 | {"c":5, "a":6, "b":7}    | ["c", "a"]     |
|    4 | {"a":8, "c":9}           | ["b", "c"]     |
|    5 | {"b":10, "":11}          | ["a"]          |
|    6 | {"":12, "":13}           | ["c"]          |
|    7 | {"":15}                  | ["a", ""]      |
|    8 | {"":17}                  | ["", ""]       |
|    9 | {"":19}                  | ["", ""]       |
|   10 | {"a":20, "b":21, "c":22} | ["", "b", "c"] |
+------+--------------------------+----------------+
8 rows in set (0.02 sec)
```

To ensure correctness, filters should only be applied at the top level
of the LIST or MAP, and their children should be read in full when late
materialization occurs.

After this pr:
```text
mysql> select * from complex_data_orc where id > 2;
+------+--------------------------+-----------------+
| id   | m                        | l               |
+------+--------------------------+-----------------+
|    3 | {"c":5, "a":6, "b":7}    | ["c", "a"]      |
|    4 | {"a":8, "c":9}           | ["b", "c"]      |
|    5 | {"b":10, "a":11}         | ["a"]           |
|    6 | {"c":12, "b":13}         | ["c"]           |
|    7 | {"a":15}                 | ["a", "a"]      |
|    8 | {"b":17}                 | ["b", "b"]      |
|    9 | {"c":19}                 | ["c", "c"]      |
|   10 | {"a":20, "b":21, "c":22} | ["a", "b", "c"] |
+------+--------------------------+-----------------+
8 rows in set (1.41 sec)
```
@gavinchou gavinchou mentioned this pull request Jun 11, 2025
@suxiaogang223 suxiaogang223 deleted the fix_orc_list_map_lazy_mat branch July 10, 2025 09:04
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

approved Indicates a PR has been approved by one committer. dev/2.1.10-merged dev/3.0.6-merged reviewed

Projects

None yet

Development

Successfully merging this pull request may close these issues.

7 participants