siddharthteotia commented on a change in pull request #8412: URL: https://github.com/apache/pinot/pull/8412#discussion_r837235644
########## File path: pinot-query-runtime/src/main/java/org/apache/pinot/query/runtime/blocks/DataTableBlock.java ########## @@ -0,0 +1,73 @@ +/** + * 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. + */ +package org.apache.pinot.query.runtime.blocks; + +import java.io.IOException; +import org.apache.pinot.common.utils.DataTable; +import org.apache.pinot.core.common.Block; +import org.apache.pinot.core.common.BlockDocIdSet; +import org.apache.pinot.core.common.BlockDocIdValueSet; +import org.apache.pinot.core.common.BlockMetadata; +import org.apache.pinot.core.common.BlockValSet; +import org.apache.pinot.core.operator.blocks.InstanceResponseBlock; +import org.slf4j.Logger; +import org.slf4j.LoggerFactory; + + +/** + * A {@code DataTableBlock} is a row-based data block backed by a {@link DataTable}. + */ +public class DataTableBlock implements Block { Review comment: We should discuss this a little bit more before going down the **row-oriented** path I think we will end up rewriting all the existing **columnar** operators into their corresponding **row-wise** counterparts in this new multi-stage query engine and that is probably a lot of unnecessary / avoidable work if we could just use a columnar / record batch like wire format for exchange messages between executors for shuffle / partition / broadcast and at least try to use existing columnar operators. I think it is ok to see if reusing existing columnar operators is possible in the new engine or may be just copy them over here and do minimal changes as needed. So it's probably ok to have 2 different versions of columnar operators (if reuse is absolutely impossible) -- one for existing engine and one for new engine What is more concerning to me is that since we are columnar (storage format, inmemory format and execution wise) but here we are kind of regressing by doing something that is not favorable for OLAP imo. I think we should stick with columnar for performance (and related benefits in OLAP) reasons because otherwise we will find ourselves doing multiple rewrites - rewrite all current columnar operators into rowwise for multi-engine to work - rewrite all multi-engine row-wise operators at a later point in future into columnar counterparts to improve performance (I am certain this will be one of the things targeted later to improve performance) -- 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: commits-unsubscr...@pinot.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org --------------------------------------------------------------------- To unsubscribe, e-mail: commits-unsubscr...@pinot.apache.org For additional commands, e-mail: commits-h...@pinot.apache.org
