github-actions[bot] commented on code in PR #69850: URL: https://github.com/apache/doris/pull/69850#discussion_r4416099011
########## regression-test/suites/changelog_p0/test_stream_scan_row_count.groovy: ########## @@ -0,0 +1,84 @@ +// Licensed to the Apache Software Foundation (ASF) under one +// or more contributor license agreements. See the NOTICE file +// distributed with this work for additional information +// regarding copyright ownership. The ASF licenses this file +// to you under the Apache License, Version 2.0 (the +// "License"); you may not use this file except in compliance +// with the License. You may obtain a copy of the License at +// +// http://www.apache.org/licenses/LICENSE-2.0 +// +// Unless required by applicable law or agreed to in writing, +// software distributed under the License is distributed on an +// "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY +// KIND, either express or implied. See the License for the +// specific language governing permissions and limitations +// under the License. + +import org.awaitility.Awaitility + +import static java.util.concurrent.TimeUnit.SECONDS + +/** + * The optimizer must estimate a stream read from the table it reads, not at one row. + * + * <p>A stream read is planned over a lightweight wrapper of the base table. The wrapper holds no + * partitions of its own, so a row count derived from its own partitions collapsed to zero and the + * statistics calculator raised that to one: a stream read of a large table looked like a one-row + * scan, and the optimizer could pick the real large side as a broadcast build. + * + * <p>This suite runs in both shared-nothing and cloud mode, and that matters: in cloud every read + * of a stream wraps the base table once the cloud read states are installed, so even a reset read + * goes through the wrapper; in shared-nothing a reset read scans the real table and only a + * snapshot read uses a wrapper. Both must be estimated from the table. + */ +suite("test_stream_scan_row_count", "nonConcurrent") { + sql "DROP STREAM IF EXISTS stats_stream FORCE" + sql "DROP TABLE IF EXISTS stats_stream_t" + sql """ + CREATE TABLE stats_stream_t ( + id BIGINT NOT NULL, + v BIGINT + ) + DUPLICATE KEY(id) + DISTRIBUTED BY HASH(id) BUCKETS 1 + PROPERTIES ( + "replication_num" = "1", + "changelog.enable" = "true", + "changelog.ttl_seconds" = "86400" + ) + """ + // Five rows exist when the stream is created; the last two are written afterwards, so the + // snapshot image holds five rows while the table holds seven. + sql "INSERT INTO stats_stream_t VALUES (1,10),(2,20),(3,30),(4,40),(5,50)" + sql "CREATE STREAM stats_stream ON TABLE stats_stream_t PROPERTIES ('show_initial_rows'='false')" Review Comment: [P2] Synchronize the initial insert before creating the stream. The test inserts five rows and immediately executes `CREATE STREAM` here, but a successful INSERT can remain committed while the local partition TSO is still -1 until publish completes. `show_initial_rows=false` records that TSO; snapshot filtering accepts only positive offsets, so `stats_stream@snapshot()` can normalize to an empty relation with no `PhysicalOlapScan`, causing the helper to fail or skip the wrapper path. Add the established `sync`/visibility wait before CREATE STREAM (and synchronize the post-create insert before explaining) so this regression deterministically captures the five-row snapshot. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected] --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
