Git Product home page Git Product logo

facebookincubator / velox Goto Github PK

View Code? Open in Web Editor NEW
3.1K 109.0 1.0K 70.7 MB

A C++ vectorized database acceleration library aimed to optimizing query engines and data processing systems.

Home Page: https://velox-lib.io/

License: Apache License 2.0

CMake 1.12% Makefile 0.03% Python 0.65% C 0.82% Shell 0.17% C++ 96.11% Batchfile 0.01% LLVM 0.02% Yacc 0.04% Thrift 0.13% Dockerfile 0.02% JavaScript 0.03% CSS 0.01% Cuda 0.65% MDX 0.19%

velox's Introduction

Velox logo

Velox is a C++ database acceleration library which provides reusable, extensible, and high-performance data processing components. These components can be reused to build compute engines focused on different analytical workloads, including batch, interactive, stream processing, and AI/ML. Velox was created by Facebook and it is currently developed in partnership with Intel, ByteDance, and Ahana.

In common usage scenarios, Velox takes a fully optimized query plan as input and performs the described computation. Considering Velox does not provide a SQL parser, a dataframe layer, or a query optimizer, it is usually not meant to be used directly by end-users; rather, it is mostly used by developers integrating and optimizing their compute engines.

Velox provides the following high-level components:

  • Type: a generic typing system that supports scalar, complex, and nested types, such as structs, maps, arrays, tensors, etc.
  • Vector: an Arrow-compatible columnar memory layout module, which provides multiple encodings, such as Flat, Dictionary, Constant, Sequence/RLE, and Bias, in addition to a lazy materialization pattern and support for out-of-order writes.
  • Expression Eval: a fully vectorized expression evaluation engine that allows expressions to be efficiently executed on top of Vector/Arrow encoded data.
  • Function Packages: sets of vectorized function implementations following the Presto and Spark semantic.
  • Operators: implementation of common data processing operators such as scans, projection, filtering, groupBy, orderBy, shuffle, hash join, unnest, and more.
  • I/O: a generic connector interface that allows different file formats (ORC/DWRF and Parquet) and storage adapters (S3, HDFS, local files) to be used.
  • Network Serializers: an interface where different wire protocols can be implemented, used for network communication, supporting PrestoPage and Spark's UnsafeRow.
  • Resource Management: a collection of primitives for handling computational resources, such as memory arenas and buffer management, tasks, drivers, and thread pools for CPU and thread execution, spilling, and caching.

Velox is extensible and allows developers to define their own engine-specific specializations, including:

  1. Custom types
  2. Simple and vectorized functions
  3. Aggregate functions
  4. Operators
  5. File formats
  6. Storage adapters
  7. Network serializers

Examples

Examples of extensibility and integration with different component APIs can be found here

Documentation

Developer guides detailing many aspects of the library, in addition to the list of available functions can be found here.

Blog posts are available here.

Getting Started

Get the Velox Source

git clone https://github.com/facebookincubator/velox.git
cd velox

Once Velox is checked out, the first step is to install the dependencies. Details on the dependencies and how Velox manages some of them for you can be found here.

Velox also provides the following scripts to help developers setup and install Velox dependencies for a given platform.

Setting up on macOS

On an Intel MacOS machine you can setup and then build like so:

$ ./scripts/setup-macos.sh
$ make

On an M1 MacOS machine you can build like so:

$ CPU_TARGET="arm64" ./scripts/setup-macos.sh
$ CPU_TARGET="arm64" make

You can also produce intel binaries on an M1, use CPU_TARGET="sse" for the above.

Setting up on aarch64 Linux (Ubuntu 20.04 or later)

On an aarch64 based machine, you can build like so:

$ CPU_TARGET="aarch64" ./scripts/setup-ubuntu.sh
$ CPU_TARGET="aarch64" make

Setting up on x86_64 Linux (Ubuntu 20.04 or later)

Once you have checked out Velox, you can setup and build like so:

$ ./scripts/setup-ubuntu.sh
$ make

Building Velox

Run make in the root directory to compile the sources. For development, use make debug to build a non-optimized debug version, or make release to build an optimized version. Use make unittest to build and run tests.

Note that,

  • Velox requires a compiler at the minimum GCC 9.0 or Clang 14.0.
  • Velox requires the CPU to support instruction sets:
    • bmi
    • bmi2
    • f16c
  • Velox tries to use the following (or equivalent) instruction sets where available:
    • On Intel CPUs
      • avx
      • avx2
      • sse
    • On ARM
      • Neon
      • Neon64

Building Velox with docker-compose

If you don't want to install the system dependencies required to build Velox, you can also build and run tests for Velox on a docker container using docker-compose. Use the following commands:

$ docker-compose build ubuntu-cpp
$ docker-compose run --rm ubuntu-cpp

If you want to increase or decrease the number of threads used when building Velox you can override the NUM_THREADS environment variable by doing:

$ docker-compose run -e NUM_THREADS=<NUM_THREADS_TO_USE> --rm ubuntu-cpp

Contributing

Check our contributing guide to learn about how to contribute to the project.

Community

The main communication channel with the Velox OSS community is through the the Velox-OSS Slack workspace. Please reach out to [email protected] to get access to Velox Slack Channel.

License

Velox is licensed under the Apache 2.0 License. A copy of the license can be found here.

velox's People

Contributors

aditi-pandit avatar ahornby avatar assignuser avatar bikramsingh91 avatar chadaustin avatar duanmeng avatar funrollloops avatar gggrace14 avatar huamengjiang avatar jinchengchenghh avatar kagamiori avatar karteekmurthys avatar kevinwilfong avatar kewang1024 avatar kgpai avatar laithsakka avatar majetideepak avatar mbasmanova avatar pedroerp avatar pramodsatya avatar r-barnes avatar rui-mo avatar tanjialiang avatar xiaoxmeng avatar yingsu00 avatar yohahaha avatar yuhta avatar zacw7 avatar zhli1142015 avatar zzhao0 avatar

Stargazers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

Watchers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

velox's Issues

Support casting for complex type in parser

This could be a duckdb limitation.

This is a follow up for #63 (WidthBucketArrayTest#failureForConstant). It could be reproduced by evaluating expression that looks like width_bucket(c0, CAST(ARRAY[] AS ARRAY(DOUBLE))). The parser would fail with:

C++ exception with description "Parser Error: syntax error at or near "ARRAY"
LINE 1: ...ELECT width_bucket(c0, CAST(ARRAY[] AS ARRAY<DOUBLE>))
                                                  ^" thrown in the test body.

Fix PrestoException in TPC-H query 21

TPC-H benchmark query 21 failed on PrestoCPP with the following Exception:
"PrestoException com.facebook.presto.sql.planner.plan.AssignUniqueId no abstract type PlanNode".

Steps to reproduce : Run unit tests testTpchQ21 in
java/presto-native-tests/src/test/java/com/facebook/presto/nativeworker/TestHiveTpchQueries.java

Build failure on Ubuntu 20.04.2 LTS

[8/612] Building CXX object velox/aggregates/CMakeFi...velox_aggregates.dir/ApproxPercentileAggregate.cpp.
FAILED: velox/aggregates/CMakeFiles/velox_aggregates.dir/ApproxPercentileAggregate.cpp.o 
/usr/bin/c++  -DBOOST_ALL_NO_LIB -DBOOST_ATOMIC_DYN_LINK -DBOOST_CONTEXT_DYN_LINK -DBOOST_FILESYSTEM_DYN_LINK -DBOOST_PROGRAM_OPTIONS_DYN_LINK -DBOOST_REGEX_DYN_LINK -DBOOST_SYSTEM_DYN_LINK -DBOOST_THREAD_DYN_LINK -DFMT_LOCALE -DGFLAGS_IS_A_DLL=0 -I../../. -isystem ../../velox -isystem ../../velox/external -isystem ../../velox/external/duckdb -isystem ../../deps/include -mavx2 -mfma -mavx -mf16c  -mbmi2 -march=native -D USE_VELOX_COMMON_BASE -g -D HAS_UNCAUGHT_EXCEPTIONS -Werror -Wall -Wextra -Wno-unused        -Wno-unused-parameter        -Wno-sign-compare        -Wno-ignored-qualifiers        -Wno-implicit-fallthrough          -Wno-empty-body          -Wno-class-memaccess          -Wno-comment          -Wno-int-in-bool-context          -Wno-redundant-move          -Wno-type-limits -O3 -DNDEBUG   -std=gnu++17 -MD -MT velox/aggregates/CMakeFiles/velox_aggregates.dir/ApproxPercentileAggregate.cpp.o -MF velox/aggregates/CMakeFiles/velox_aggregates.dir/ApproxPercentileAggregate.cpp.o.d -o velox/aggregates/CMakeFiles/velox_aggregates.dir/ApproxPercentileAggregate.cpp.o -c ../../velox/aggregates/ApproxPercentileAggregate.cpp
In file included from ../.././velox/vector/BaseVector.h:38,
                 from ../.././velox/vector/ComplexVector.h:26,
                 from ../.././velox/connectors/Connector.h:20,
                 from ../.././velox/core/PlanNode.h:18,
                 from ../.././velox/exec/Aggregate.h:19,
                 from ../../velox/aggregates/ApproxPercentileAggregate.cpp:19:
../.././velox/vector/VectorStream.h: In instantiation of ??T facebook::velox::ByteStream::read() [with T = double]??:
../../velox/aggregates/ApproxPercentileAggregate.cpp:52:8:   required from ??folly::TDigest facebook::velox::aggregate::{anonymous}::deserialize(TByteStream&) [with TByteStream = facebook::velox::ByteStream]??
../../velox/aggregates/ApproxPercentileAggregate.cpp:99:32:   required from here
../.././velox/vector/VectorStream.h:297:41: error: dereferencing type-punned pointer will break strict-aliasing rules [-Werror=strict-aliasing]
  297 |     return *reinterpret_cast<const T*>(&value);
      |                                         ^~~~~
cc1plus: all warnings being treated as errors
[15/612] Building CXX object velox/aggregates/CMakeFiles/velox_aggregates.dir/MinMaxByAggregates.cpp.o
ninja: build stopped: subcommand failed.
make[1]: *** [Makefile:50: build] Error 1
make[1]: Leaving directory '/space2/damianr/tmp/velox'
make: *** [Makefile:57: release] Error 2
~/t/s/velox> :main! [status=2] cat /etc/issue
Ubuntu 20.04.2 LTS \n \l

~/t/s/velox> :main! /usr/bin/c++ --version
c++ (Ubuntu 9.3.0-17ubuntu1~20.04) 9.3.0
Copyright (C) 2019 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

Fix error: VeloxRuntimeError: !leftKeys_.empty() in TPC-H tests

Several TPC-H benchmark queries (Q2, Q11, Q17, Q20) failed on PrestoCPP with the error:
VeloxRuntimeError: !leftKeys_.empty()

Stack trace

Caused by: java.lang.RuntimeException: !leftKeys_.empty()
at com.facebook.presto.tests.AbstractTestingPrestoClient.execute(AbstractTestingPrestoClient.java:124)
at com.facebook.presto.tests.DistributedQueryRunner.execute(DistributedQueryRunner.java:552)
at com.facebook.presto.tests.DistributedQueryRunner.execute(DistributedQueryRunner.java:520)
at com.facebook.presto.tests.QueryAssertions.assertQuery(QueryAssertions.java:148)
... 28 more
Caused by: VeloxRuntimeError: !leftKeys_.empty()

Steps to reproduce : Run unit tests testTpchQ2, testTpchQ11, testTpchQ17 and testTpchQ20 in
java/presto-native-tests/src/test/java/com/facebook/presto/nativeworker/TestHiveTpchQueries.java

Support extra join filter for SEMI/ANTI join

Currently we don't support SEMI/ANTI join with extra join filter in hash join, and also merge join. In Velox, we only supports SEMI/ANTI join with no join filter for hash join. In Spark, we support this type of query. Creating an issue here to track progress after talking to @mbasmanova offline. We are working on this issue now.

Add support for ORC reader

Currently there are no ORC reader support yet:

presto:tpch_1_partitioned> show create table lineitem_short;
Create Table
CREATE TABLE hive.tpch_1_partitioned.lineitem_short (
"orderkey" bigint,
"partkey" bigint,
"linenumber" integer,
"suppkey" bigint,
"linestatus" varchar(1),
"returnflag" varchar(1)
)
WITH (
format = 'ORC',
partitioned_by = ARRAY['linestatus','returnflag']
)
(1 row)
presto:tpch_1_partitioned> select count(*) from hive.tpch_1_partitioned.lineitem_short;

Query 20220109_005204_00007_65utr failed: Unknown file format org.apache.hadoop.hive.ql.io.orc.OrcInputFormat
VeloxRuntimeError: Unknown file format org.apache.hadoop.hive.ql.io.orc.OrcInputFormat

Note: org.apache.hadoop.hive.ql.io.orc.OrcInputFormat is for ORC, com.facebook.hive.orc.OrcInputFormat is for DWRF

Another issue with Folly: Cannot found folly library from rpath

After fixing #360 by adding FOLLY_HAVE_INT128_T (I used homebrew, not the setup-macos.sh), I had another Folly issue as follows.

ld: file not found: @rpath/libfolly.0.58.0-dev.dylib for architecture x86_64
clang: error: linker command failed with exit code 1 (use -v to see invocation)
make[4]: *** [velox/common/base/benchmarks/velox_common_base_benchmarks] Error 1
make[3]: *** [velox/common/base/benchmarks/CMakeFiles/velox_common_base_benchmarks.dir/all] Error 2
make[3]: *** Waiting for unfinished jobs....

It looks weird because /usr/local/lib/libfollybenchmark.dylib and libfolly_test_util.dylib both load libfolly.0.58.0-dev.dylib from @rpath/libfolly.0.58.0-dev.dylib, but they don't specify RPATH?

Anyway, it is a bit hacky, but I manually added rpath by doing:

sudo install_name_tool -add_rpath /usr/local/lib  /usr/local/lib/libfollybenchmark.dylib

After that, I can successfully build Velox locally on Mac OS. Maybe this can be resolved from Folly side? I'm not sure. Hopefully this can be useful for others encountering the same issue.

CMake failed to find the `glog` module in ubuntu 20.04.

After #500, CMake failed to find the glog module on ubuntu 20.04. Please see error message here. It works fine on macOS. I guess glog is built with Make other than CMake on ubuntu so that glog-config.cmake doesn't exist.

To fix this, we need to provide Findglog.cmake which is currently located in build\fbcode_builder with the name FindGlog.cmake

Let me know, if it is OK, I can create a PR

Identify missing features for TPC-H queries

Like we discussed on yesterday's sync, let's use the e2e test suite to experiment with the different TPC-H queries, and identify the features we currently have missing. When we do, let's open github issues so we can coordinate between the TPC-H stakeholders.

This is the file we could use to add the queries:

https://github.com/facebookexternal/presto_cpp/blob/master/java/presto-native-tests/src/test/java/com/facebook/presto/nativeworker/TestHiveQueries.java

Is this the expected way to parallelize?

Hi everyone,

I'm trying to get a few TPC-H-like queries running by building the query plans manually.

For example, TPC-H 13:

auto plan = PlanBuilder()
             .values({tables.get("customer")})
             .hashJoin(
                 {0},
                 {0},
                 PlanBuilder()
                     .values({tables.get("orders")})
                     .planNode(),
                 R"(not REGEXP_LIKE(o_comment, '^special.*?requests'))",
                 {0, 1, 2, 3})
             .singleAggregation({0}, {"count(o_orderkey)"})
             .project({"c_custkey", "a0"}, {"c_custkey", "c_count"})
             .singleAggregation({1}, {"count(1)"})
             .project({"c_count", "a0"}, {"c_count", "custdist"})
             .orderBy({0, 1}, {kDescNullsLast, kDescNullsLast}, false)
             .limit(0, 1, false)
             .planNode();
auto result = readSingleValue(plan);

I tried to parallelize the execution using the CursorParameters:

params.maxDrivers = 16;
params.numResultDrivers = 1;

This appears to be working, although it's on a single core ~95% of the time. params.numResultDrivers = 1; seem fishy to me, but without that the execution hangs.

Is this the correct approach, or am I missing something?
Thanks in advance!

Improve AWS error message description

I used an invalid key for accessing S3. I get the following error message

Query 20220107_170907_00001_ctpvx failed: Failed to initialize S3 file with bucket 'foodata' and key 'hive_data/tpch10/nation/20211202_232845_00006_ncbbk_66a67b60-d4e4-4885-920e-4f0a1a1dc75a' due to 15:No response body.

It is not clear that the error is related to an invalid key.

Add support for DATE . This is used in 12 TPC-H queries.

DATE is used in TPC-H queries 1, 3, 4, 5, 6, 7, 8, 10, 12, 14, 15, 20

Steps to reproduce : Run unit tests testTpchQ1, testTpchQ3 etc in
java/presto-native-tests/src/test/java/com/facebook/presto/nativeworker/TestHiveTpchQueries.java

Note: The DATE based predicates might have been commented in the underlying SQL file to run the rest of the query in the test. Please fix the underlying SQL if needed.

ParquetReader passes wrong columnIds array to DuckDB::ParquetReader

The following query fails with index out of bound error:

select count(*) from lineitem where partkey <20000000;

Call stack

std::__1::unique_ptr<duckdb::ColumnReader, std::__1::default_delete<duckdb::ColumnReader> >::get() const memory:2318
duckdb::StructColumnReader::GetChildReader(unsigned long long) parquet-amalgamation.cpp:13520
duckdb::ParquetReader::ScanInternal(duckdb::ParquetReaderScanState&, duckdb::DataChunk&) parquet-amalgamation.cpp:16349
duckdb::ParquetReader::Scan(duckdb::ParquetReaderScanState&, duckdb::DataChunk&) parquet-amalgamation.cpp:16283
facebook::velox::parquet::ParquetRowReader::next(unsigned long long, std::__1::shared_ptr<facebook::velox::BaseVector>&) ParquetReader.cpp:150
facebook::velox::connector::hive::HiveDataSource::next(unsigned long long) HiveConnector.cpp:495
facebook::velox::exec::TableScan::getOutput() TableScan.cpp:95
facebook::velox::exec::Driver::runInternal(std::__1::shared_ptr<facebook::velox::exec::Driver>&, std::__1::shared_ptr<facebook::velox::exec::BlockingState>*) Driver.cpp:375
facebook::velox::exec::Driver::run(std::__1::shared_ptr<facebook::velox::exec::Driver>) Driver.cpp:459
facebook::velox::exec::Driver::enqueue(std::__1::shared_ptr<facebook::velox::exec::Driver>)::$_0::operator()() const Driver.cpp:195
void folly::detail::function::FunctionTraits<void ()>::callSmall<facebook::velox::exec::Driver::enqueue(std::__1::shared_ptr<facebook::velox::exec::Driver>)::$_0>(folly::detail::function::Data&) Function.h:371
folly::detail::function::FunctionTraits<void ()>::operator()() Function.h:400
folly::ThreadPoolExecutor::runTask(std::__1::shared_ptr<folly::ThreadPoolExecutor::Thread> const&, folly::ThreadPoolExecutor::Task&&) Exception.h:279
folly::ThreadPoolExecutor::runTask(std::__1::shared_ptr<folly::ThreadPoolExecutor::Thread> const&, folly::ThreadPoolExecutor::Task&&) Executor.h:235
folly::ThreadPoolExecutor::runTask(std::__1::shared_ptr<folly::ThreadPoolExecutor::Thread> const&, folly::ThreadPoolExecutor::Task&&) ThreadPoolExecutor.cpp:116
folly::CPUThreadPoolExecutor::threadRun(std::__1::shared_ptr<folly::ThreadPoolExecutor::Thread>) CPUThreadPoolExecutor.cpp:302
decltype(*(std::__1::forward<folly::ThreadPoolExecutor*&>(fp0)).*fp(std::__1::forward<std::__1::shared_ptr<folly::ThreadPoolExecutor::Thread>&>(fp1))) std::__1::__invoke<void (folly::ThreadPoolExecutor::*&)(std::__1::shared_ptr<folly::ThreadPoolExecutor::Thread>), folly::ThreadPoolExecutor*&, std::__1::shared_ptr<folly::ThreadPoolExecutor::Thread>&, void>(void (folly::ThreadPoolExecutor::*&)(std::__1::shared_ptr<folly::ThreadPoolExecutor::Thread>), folly::ThreadPoolExecutor*&, std::__1::shared_ptr<folly::ThreadPoolExecutor::Thread>&) type_traits:3688
std::__1::__bind_return<void (folly::ThreadPoolExecutor::*)(std::__1::shared_ptr<folly::ThreadPoolExecutor::Thread>), std::__1::tuple<folly::ThreadPoolExecutor*, std::__1::shared_ptr<folly::ThreadPoolExecutor::Thread> >, std::__1::tuple<>, __is_valid_bind_return<void (folly::ThreadPoolExecutor::*)(std::__1::shared_ptr<folly::ThreadPoolExecutor::Thread>), std::__1::tuple<folly::ThreadPoolExecutor*, std::__1::shared_ptr<folly::ThreadPoolExecutor::Thread> >, std::__1::tuple<> >::value>::type std::__1::__apply_functor<void (folly::ThreadPoolExecutor::*)(std::__1::shared_ptr<folly::ThreadPoolExecutor::Thread>), std::__1::tuple<folly::ThreadPoolExecutor*, std::__1::shared_ptr<folly::ThreadPoolExecutor::Thread> >, 0ul, 1ul, std::__1::tuple<> >(void (folly::ThreadPoolExecutor::*&)(std::__1::shared_ptr<folly::ThreadPoolExecutor::Thread>), std::__1::tuple<folly::ThreadPoolExecutor*, std::__1::shared_ptr<folly::ThreadPoolExecutor::Thread> >&, std::__1::__tuple_indices<0ul, 1ul>, std::__1::tuple<>&&) functional:2852
std::__1::__bind_return<void (folly::ThreadPoolExecutor::*)(std::__1::shared_ptr<folly::ThreadPoolExecutor::Thread>), std::__1::tuple<folly::ThreadPoolExecutor*, std::__1::shared_ptr<folly::ThreadPoolExecutor::Thread> >, std::__1::tuple<>, __is_valid_bind_return<void (folly::ThreadPoolExecutor::*)(std::__1::shared_ptr<folly::ThreadPoolExecutor::Thread>), std::__1::tuple<folly::ThreadPoolExecutor*, std::__1::shared_ptr<folly::ThreadPoolExecutor::Thread> >, std::__1::tuple<> >::value>::type std::__1::__bind<void (folly::ThreadPoolExecutor::*)(std::__1::shared_ptr<folly::ThreadPoolExecutor::Thread>), folly::ThreadPoolExecutor*, std::__1::shared_ptr<folly::ThreadPoolExecutor::Thread>&>::operator()<>() functional:2885
void folly::detail::function::FunctionTraits<void ()>::callSmall<std::__1::__bind<void (folly::ThreadPoolExecutor::*)(std::__1::shared_ptr<folly::ThreadPoolExecutor::Thread>), folly::ThreadPoolExecutor*, std::__1::shared_ptr<folly::ThreadPoolExecutor::Thread>&> >(folly::detail::function::Data&) Function.h:371
folly::detail::function::FunctionTraits<void ()>::operator()() Function.h:400
folly::NamedThreadFactory::newThread(folly::Function<void ()>&&)::'lambda'()::operator()() NamedThreadFactory.h:40
decltype(std::__1::forward<folly::NamedThreadFactory::newThread(folly::Function<void ()>&&)::'lambda'()>(fp)()) std::__1::__invoke<folly::NamedThreadFactory::newThread(folly::Function<void ()>&&)::'lambda'()>(folly::NamedThreadFactory::newThread(folly::Function<void ()>&&)::'lambda'()&&) type_traits:3747
void std::__1::__thread_execute<std::__1::unique_ptr<std::__1::__thread_struct, std::__1::default_delete<std::__1::__thread_struct> >, folly::NamedThreadFactory::newThread(folly::Function<void ()>&&)::'lambda'()>(std::__1::tuple<std::__1::unique_ptr<std::__1::__thread_struct, std::__1::default_delete<std::__1::__thread_struct> >, folly::NamedThreadFactory::newThread(folly::Function<void ()>&&)::'lambda'()>&, std::__1::__tuple_indices<>) thread:280
void* std::__1::__thread_proxy<std::__1::tuple<std::__1::unique_ptr<std::__1::__thread_struct, std::__1::default_delete<std::__1::__thread_struct> >, folly::NamedThreadFactory::newThread(folly::Function<void ()>&&)::'lambda'()> >(void*) thread:291
_pthread_start 0x00007fff205a28fc
thread_start 0x00007fff2059e443

This is because DuckDB creates readers for all table columns even they are not used in the query and I created issue duckdb/duckdb#2898
while ParquetRowReader only include the columns with filters:

ParquetRowReader::ParquetRowReader(
    std::shared_ptr<::duckdb::ParquetReader> reader,
    const dwio::common::RowReaderOptions& options,
    memory::MemoryPool& pool)
    : reader_(std::move(reader)), pool_(pool) {
...
  std::vector<::duckdb::column_t> columnIds;
  columnIds.reserve(rowType_->size());
  duckdbRowType_.reserve(rowType_->size());
  for (auto& node : filter) {
    columnIds.push_back(node.column);
    duckdbRowType_.push_back(reader_->return_types[node.column]);
  }

In DuckDB ParquetReader::ScanInternal(), it gets the reader

auto file_col_idx = state.column_ids[filter_col.first];

But filter_col.first = 1 (partkey has hive column index 1) and column_ids array only has 1 element. Reading index 1 caused wrong file_col_idx.

Actually it's bad practice to pass in the state and columnIds to DuckDB ParquetReader from Velox. The state should be DuckDB ParquetReader internal state and should not be passed from outside. It also needs to set the column_ids correctly within DuckDB. Note that DuckDB reads the file metadata already during initialization, and the schema has all columns information and can be used to construct column_ids array.

Additionally the column_ids array doesn't seem necessary, if both column_id and filter_col.first are hiveColumnIndexes. Then the above line should be

auto file_col_idx = filter_col.first;

Furthermore, DuckDB should not create so many readers, one for each table column. It should only create readers for the columns needed.

I think DuckDB needs big refactoring to manage its states correctly before we can work on any additional optimizations.

Fix LOJ query 13 in TPC-H tests

TPC-H q13 has an LOJ that seemed to run indefinitely in the local environment. The understanding is that only INNER join is supported today so at the very least this query should've failed cleanly.

Steps to reproduce : Run unit tests testTpchQ13 in
java/presto-native-tests/src/test/java/com/facebook/presto/nativeworker/TestHiveTpchQueries.java

Add support for EXTRACT Year from Date. This is used in 3 TPC-H queries.

TPC-H queries 7, 8, 9 group by a column that is obtained using EXTRACT Year from Date. Add support for this functionality in PrestoCPP.

Steps to reproduce : Run unit tests testTpchQ7(8)(9) in
java/presto-native-tests/src/test/java/com/facebook/presto/nativeworker/TestHiveTpchQueries.java

(The test also fails as DATE type is not supported for the EXTRACT functionality)

How connect presto with velox?

We want to try velox with presto, it seems the todo includes

  1. define protocol between presto and velox, build a binary with velox, and list on a port x
  2. presto connect port x and send plan tree, receive the result

is it right ? thanks.

Why implementation of Driver::runInternal is so complicated๏ผŸ

I checked out the implementation of Driver::runInternal๏ผŒit looks so complicated:

  1. why not use coroutine to simplify the block of pyhsical thread
  2. why not push data from bottom to top

Both 1 and 2 can make the code more easier, more maintainable, and also with high concurrency

Add support for LIKE operator

Presto's documentation about LIKE operator: https://prestodb.io/docs/current/functions/comparison.html#like

LIKE operator can be implemented by translating the pattern to a regular expression and using regexp_like function to evaluate it.

regexp_like already exists. See velox/functions/prestosql/VectorFunctions.cpp

Presto's conversion from like pattern to regex pattern can be found at https://github.com/prestodb/presto/blob/master/presto-main/src/main/java/com/facebook/presto/type/LikeFunctions.java#L174

We can add vector function "like" that takes two parameters, likePattern and escapeChar (optional), translates likePattern and escapeChar into a regular expression and invokes regexp_like. To avoid re-compiling regular expressions multiple times, the new function can be implemented as stateful and compile regular expression from the constant inputs in the constructor. See makeRe2Search in velox/functions/lib/Re2Functions.h

In Presto query plan, c LIKE '<pattern>' appears as like(c, cast('<pattern>' as LikePattern)) and c LIKE '<pattern>' ESCAPE '<escape-char>' appears as like(c, like_pattern('<pattern>', '<escape-char>')). We'll need to translate these expressions to like(c, ) and like(c, '<pattern>', '<escape-char>') respectively. See tryConvertCast in presto_cpp/main/types/PrestoToVeloxExpr.cpp for a similar logic applied to regular expressions.

To quickly try LIKE operator, edit e2e test to add a query like this:

assertQuery("SELECT * FROM lineitem WHERE comment LIKE '%afa%'");
assertQuery("SELECT * FROM lineitem WHERE comment LIKE '%afa#%' ESCAPE '#'");

CC: @spershin @pedroerp @aditi-pandit @majetideepak @kgpai

Improve test coverage for existing tests

Some of the current tests do not have coverage for all the supported types. We should re-use the input data where possible and simplify adding tests for all the types.

Parquet reader throws EXC_BAD_ACCESS on simple query with filter

After enabling filter pushdown prestodb/presto#17161 on Presto, the Parquet reader code path is activated. However it fails to run any query. A simple query with filter yields the " EXC_BAD_ACCESS (code=EXC_I386_GPFLT)" error.

Query:
select sum(orderkey) from lineitem where partkey =1;

The stack trace is

facebook::velox::filesystems::(anonymous namespace)::registeredFileSystems() FileSystems.cpp:33
duckdb::AllocatedData::Reset() duckdb.cpp:4392
duckdb::AllocatedData::~AllocatedData() duckdb.cpp:4385
duckdb::AllocatedData::~AllocatedData() duckdb.cpp:4384
std::__1::default_delete<duckdb::AllocatedData>::operator()(duckdb::AllocatedData*) const memory:2084
std::__1::unique_ptr<duckdb::AllocatedData, std::__1::default_delete<duckdb::AllocatedData> >::reset(duckdb::AllocatedData*) memory:2345
std::__1::unique_ptr<duckdb::AllocatedData, std::__1::default_delete<duckdb::AllocatedData> >::~unique_ptr() memory:2299
std::__1::unique_ptr<duckdb::AllocatedData, std::__1::default_delete<duckdb::AllocatedData> >::~unique_ptr() memory:2299
duckdb::ResizeableBuffer::~ResizeableBuffer() parquet-amalgamation.hpp:7031
duckdb::ResizeableBuffer::~ResizeableBuffer() parquet-amalgamation.hpp:7031
duckdb::ParquetReaderScanState::~ParquetReaderScanState() parquet-amalgamation.hpp:7452
duckdb::ParquetReaderScanState::~ParquetReaderScanState() parquet-amalgamation.hpp:7452
facebook::velox::parquet::ParquetRowReader::~ParquetRowReader() ParquetReader.h:33
facebook::velox::parquet::ParquetRowReader::~ParquetRowReader() ParquetReader.h:33
facebook::velox::parquet::ParquetRowReader::~ParquetRowReader() ParquetReader.h:33
std::__1::default_delete<facebook::velox::dwio::common::RowReader>::operator()(facebook::velox::dwio::common::RowReader*) const memory:2084
std::__1::unique_ptr<facebook::velox::dwio::common::RowReader, std::__1::default_delete<facebook::velox::dwio::common::RowReader> >::reset(facebook::velox::dwio::common::RowReader*) memory:2345
facebook::velox::connector::hive::HiveDataSource::next(unsigned long long) HiveConnector.cpp:542
facebook::velox::exec::TableScan::getOutput() TableScan.cpp:95
facebook::velox::exec::Driver::runInternal(std::__1::shared_ptr<facebook::velox::exec::Driver>&, std::__1::shared_ptr<facebook::velox::exec::BlockingState>*) Driver.cpp:409
facebook::velox::exec::Driver::run(std::__1::shared_ptr<facebook::velox::exec::Driver>) Driver.cpp:493
facebook::velox::exec::Driver::enqueue(std::__1::shared_ptr<facebook::velox::exec::Driver>)::$_0::operator()() const Driver.cpp:229
void folly::detail::function::FunctionTraits<void ()>::callSmall<facebook::velox::exec::Driver::enqueue(std::__1::shared_ptr<facebook::velox::exec::Driver>)::$_0>(folly::detail::function::Data&) Function.h:371
folly::detail::function::FunctionTraits<void ()>::operator()() Function.h:400
folly::ThreadPoolExecutor::runTask(std::__1::shared_ptr<folly::ThreadPoolExecutor::Thread> const&, folly::ThreadPoolExecutor::Task&&) Exception.h:279
folly::ThreadPoolExecutor::runTask(std::__1::shared_ptr<folly::ThreadPoolExecutor::Thread> const&, folly::ThreadPoolExecutor::Task&&) Executor.h:235
folly::ThreadPoolExecutor::runTask(std::__1::shared_ptr<folly::ThreadPoolExecutor::Thread> const&, folly::ThreadPoolExecutor::Task&&) ThreadPoolExecutor.cpp:116
folly::CPUThreadPoolExecutor::threadRun(std::__1::shared_ptr<folly::ThreadPoolExecutor::Thread>) CPUThreadPoolExecutor.cpp:302
decltype(*(std::__1::forward<folly::ThreadPoolExecutor*&>(fp0)).*fp(std::__1::forward<std::__1::shared_ptr<folly::ThreadPoolExecutor::Thread>&>(fp1))) std::__1::__invoke<void (folly::ThreadPoolExecutor::*&)(std::__1::shared_ptr<folly::ThreadPoolExecutor::Thread>), folly::ThreadPoolExecutor*&, std::__1::shared_ptr<folly::ThreadPoolExecutor::Thread>&, void>(void (folly::ThreadPoolExecutor::*&)(std::__1::shared_ptr<folly::ThreadPoolExecutor::Thread>), folly::ThreadPoolExecutor*&, std::__1::shared_ptr<folly::ThreadPoolExecutor::Thread>&) type_traits:3688
std::__1::__bind_return<void (folly::ThreadPoolExecutor::*)(std::__1::shared_ptr<folly::ThreadPoolExecutor::Thread>), std::__1::tuple<folly::ThreadPoolExecutor*, std::__1::shared_ptr<folly::ThreadPoolExecutor::Thread> >, std::__1::tuple<>, __is_valid_bind_return<void (folly::ThreadPoolExecutor::*)(std::__1::shared_ptr<folly::ThreadPoolExecutor::Thread>), std::__1::tuple<folly::ThreadPoolExecutor*, std::__1::shared_ptr<folly::ThreadPoolExecutor::Thread> >, std::__1::tuple<> >::value>::type std::__1::__apply_functor<void (folly::ThreadPoolExecutor::*)(std::__1::shared_ptr<folly::ThreadPoolExecutor::Thread>), std::__1::tuple<folly::ThreadPoolExecutor*, std::__1::shared_ptr<folly::ThreadPoolExecutor::Thread> >, 0ul, 1ul, std::__1::tuple<> >(void (folly::ThreadPoolExecutor::*&)(std::__1::shared_ptr<folly::ThreadPoolExecutor::Thread>), std::__1::tuple<folly::ThreadPoolExecutor*, std::__1::shared_ptr<folly::ThreadPoolExecutor::Thread> >&, std::__1::__tuple_indices<0ul, 1ul>, std::__1::tuple<>&&) functional:2852
std::__1::__bind_return<void (folly::ThreadPoolExecutor::*)(std::__1::shared_ptr<folly::ThreadPoolExecutor::Thread>), std::__1::tuple<folly::ThreadPoolExecutor*, std::__1::shared_ptr<folly::ThreadPoolExecutor::Thread> >, std::__1::tuple<>, __is_valid_bind_return<void (folly::ThreadPoolExecutor::*)(std::__1::shared_ptr<folly::ThreadPoolExecutor::Thread>), std::__1::tuple<folly::ThreadPoolExecutor*, std::__1::shared_ptr<folly::ThreadPoolExecutor::Thread> >, std::__1::tuple<> >::value>::type std::__1::__bind<void (folly::ThreadPoolExecutor::*)(std::__1::shared_ptr<folly::ThreadPoolExecutor::Thread>), folly::ThreadPoolExecutor*, std::__1::shared_ptr<folly::ThreadPoolExecutor::Thread>&>::operator()<>() functional:2885
void folly::detail::function::FunctionTraits<void ()>::callSmall<std::__1::__bind<void (folly::ThreadPoolExecutor::*)(std::__1::shared_ptr<folly::ThreadPoolExecutor::Thread>), folly::ThreadPoolExecutor*, std::__1::shared_ptr<folly::ThreadPoolExecutor::Thread>&> >(folly::detail::function::Data&) Function.h:371
folly::detail::function::FunctionTraits<void ()>::operator()() Function.h:400
folly::NamedThreadFactory::newThread(folly::Function<void ()>&&)::'lambda'()::operator()() NamedThreadFactory.h:40
decltype(std::__1::forward<folly::NamedThreadFactory::newThread(folly::Function<void ()>&&)::'lambda'()>(fp)()) std::__1::__invoke<folly::NamedThreadFactory::newThread(folly::Function<void ()>&&)::'lambda'()>(folly::NamedThreadFactory::newThread(folly::Function<void ()>&&)::'lambda'()&&) type_traits:3747
void std::__1::__thread_execute<std::__1::unique_ptr<std::__1::__thread_struct, std::__1::default_delete<std::__1::__thread_struct> >, folly::NamedThreadFactory::newThread(folly::Function<void ()>&&)::'lambda'()>(std::__1::tuple<std::__1::unique_ptr<std::__1::__thread_struct, std::__1::default_delete<std::__1::__thread_struct> >, folly::NamedThreadFactory::newThread(folly::Function<void ()>&&)::'lambda'()>&, std::__1::__tuple_indices<>) thread:280
void* std::__1::__thread_proxy<std::__1::tuple<std::__1::unique_ptr<std::__1::__thread_struct, std::__1::default_delete<std::__1::__thread_struct> >, folly::NamedThreadFactory::newThread(folly::Function<void ()>&&)::'lambda'()> >(void*) thread:291
_pthread_start 0x00007fff203b78fc
thread_start 0x00007fff203b3443

I have root caused the problem. It was because ParquetReader has a duckDB allocator as its member, and it's not managed by any smart pointers. Then:

RowVectorPtr HiveDataSource::next(uint64_t size) {
      ...
    reader_.reset();    // This caused the the ParquetReader object to be destructed and its member allocator also destructed.
    rowReader_.reset();    // ParquetRowReader is trying to destruct the buffers and it makes use of the just deleted allocator.
}

A fix will be sent soon. The idea is not to keep the allocator as a plain member in ParquetReader since it's not used in that class other than getting the types. Other alternative fixes maybe

  1. revert the order of the reset() function. This works but it's not the right way.
  2. Use smart pointer to manage the allocator object. This requires a lot of change in DuckDB code.
    By looking at DuckDB implementation, it seems the allocator was intented to be alive throughout the query lifetime, and managed in the config that is static singleton. So I will try the approach to make the owner of the allocator ParquetRowReader instead of ParquetReader.

However I wonder why these readers are to be reset for every batch(1024 rows). Constructing and destructing these reader objects are costly operations and they should be reused for the split lifetime. @mbasmanova Is there any special reason it's done this way?

Fix TPC-H query 19

Fix TPC-H Q19 run. It failed with error "Failed with VeloxUserError: Unsupported input type for the IN predicate: DOUBLE".

Note: This error is a red-herring imo since there isn't an IN predicate using a DOUBLE type in that SQL per se.

Steps to reproduce : Run unit test testTpchQ19 in
java/presto-native-tests/src/test/java/com/facebook/presto/nativeworker/TestHiveTpchQueries.java

Fail to build with with compilation error on Folly

I tried to build this on Mac OS, but saw the error as follows:

/usr/local/include/folly/Conv.h:744:41: error: no matching function for call to 'estimateSpaceNeeded'
  return estimateSpaceToReserve(sofar + estimateSpaceNeeded(v), vs...);                                                                                                                        
                                        ^~~~~~~~~~~~~~~~~~~

I looked at Conv.h quickly, there are some candidate templates. But based on the message of compiler, seems these templates are not suitable for unsigned __int128 so the compiler cannot find a matching function of estimateSpaceNeeded.

Benchmark array_except function

It would be good to create a microbenchmark binary for array_except. There are examples in the codebase like velox/functions/lib/benchmarks/Re2FunctionsBenchmarks.cpp. These help to understand where the bottlenecks for these functions are.

https://prestodb.io/blog/2020/12/04/typedset describes certain optimizations for array functions in presto. The benchmark would help us assess if there's value in working in the hashmap optimization described in the link above.

Is it possible to support ARM64 Neon?

It seems all SIMD instructions have been abstracted in SimdUtil.h. Is it possible to implement a ARM64 Neon version of SimdUtil. If yes, I'll happy to try some works.

Fix PrestoException in TPC-H query 22

TPC-H benchmark query 22 failed on PrestoCPP with the following Exception:
"PrestoException com.facebook.presto.sql.planner.plan.EnforceSingleRowNode no abstract type PlanNode"

Steps to reproduce : Run unit tests testTpchQ22 in
java/presto-native-tests/src/test/java/com/facebook/presto/nativeworker/TestHiveTpchQueries.java

Add a TPC-H connector

Similarly to what Presto has for java, let's create a native TPC-H connector for Velox so we can easily generate synthetic TPC-H data on-the-fly. We could leverage duckdb's tpc-h generator, which will generate duck vector that can be easily converted into Velox vectors.

This is some documentation on the java connectos:

https://prestodb.io/docs/current/connector/tpch.html

Implement window functions in Velox

Window functions https://prestodb.io/docs/current/functions/window.html#functions-window are a special category of analytic functions in SQL.

These are heavily used in TPC-DS benchmark and also critical to other client SQL workloads.

This issue tracks their implementation in Velox.

Efficient Processing of Window Functions in Analytical SQL Queries VLDB paper: http://www.vldb.org/pvldb/vol8/p1058-leis.pdf

Window functions in DuckDB: https://duckdb.org/docs/sql/window_functions

Parquet and S3 support

The project README mentions that Parquet and S3 are supported, but I couldn't find any reference in the repo. Can someone provide more information on this?

Support infinity() and NaN() when constructing array in DuckParser

This is a follow up for #63 (WidthBucketArrayTest#failureForConstant). It could be reproduced by evaluating expression that look like width_bucket(c0, ARRAY[infinity()]) or width_bucket(c0, ARRAY[nan()]). It would fail with the following information:

Exception: VeloxUserError
Error Source: USER
Error Code: UNSUPPORTED
Reason: Array literal elements need to be constant
Retriable: False
Function: parseOperatorExpr
File: /Users/shixuan/presto/velox/velox/duckdb/conversion/DuckParser.cpp
Line: 218

Add support for INTERVAL. This is used in 9 TPC-H queries.

Intervals are used in TPC-H queries 1, 4, 5, 6, 10, 12, 14, 15, 20

Steps to reproduce : Run unit tests testTpchQ1, testTpchQ4, etc in
java/presto-native-tests/src/test/java/com/facebook/presto/nativeworker/TestHiveTpchQueries.java

Note: In several tests the predicates with INTERVAL are commented out in the sql files to test the rest of the query. Please take a look at the sql and un-comment the predicates if needed.

fromUnixtime() crashes if it gets a NaN or Inf

functions/common/DateTimeImpl.h:29 crashes UBSAN if the double passed as a parameter is NaN or Inf:

===
Stack trace example:

buck-out/dev/gen/aab7ed39/f4d/functions/common/f4d_functions_common#header-mode-symlink-tree-with-header-map,headers/f4d/functions/common/DateTimeImpl.h:33:20: runtime error: -nan is outside the range of representable values of type 'long'
    #0 0x7fdc359711db in fromUnixtime f4d/functions/common/DateTimeImpl.h:33         
    #1 0x7fdc359711db in call f4d/functions/common/DateTimeFunctions.h:32           
    #2 0x7fdc359711db in call f4d/core/ScalarFunction.h:254                                                                    
    #3 0x7fdc359711db in doApplyNotNull<1, double, 0> f4d/expression/VectorFunctionAdapter.h:297
    #4 0x7fdc359711db in doApplyNotNull<0, const facebook::f4d::exec::VectorReader<double, void>, 0> f4d/expression/VectorFunctionAdapter.h:287
    #5 0x7fdc359711db in _ZZNK8facebook3f4d4exec13VectorAdapterINS0_4core9UDFHolderINS0_9functions17udf_from_unixtime3udfINS1_10VectorExecEEES8_NS0_9TimestampEJdEEEE7iterateIJNS1_12VectorReaderIdvEEEEEvRNSC_12ApplyContextEbDpRKT_ENKUlTyT_E_clIiEEDaSM_ f4d
/expression/VectorFunctionAdapter.h:135                                                                                        
    #6 0x7fdc359729c8 in _ZZN8facebook3f4d4bits10forEachBitIZNKS0_4exec13VectorAdapterINS0_4core9UDFHolderINS0_9functions17udf_from_unixtime3udfINS3_10VectorExecEEESA_NS0_9TimestampEJdEEEE7iterateIJNS3_12VectorReaderIdvEEEEEvRNSE_12ApplyContextEbDpRKT_EUl
TyT_E_EEvPKmiibSO_ENKUlimE_clEim f4d/common/base/BitUtil.h:347                                                                 
    #7 0x7fdc35972425 in _ZN8facebook3f4d4bits11forEachWordIZNS1_10forEachBitIZNKS0_4exec13VectorAdapterINS0_4core9UDFHolderINS0_9functions17udf_from_unixtime3udfINS4_10VectorExecEEESB_NS0_9TimestampEJdEEEE7iterateIJNS4_12VectorReaderIdvEEEEEvRNSF_12Apply
ContextEbDpRKT_EUlTyT_E_EEvPKmiibSP_EUlimE_ZNS3_ISQ_EEvSS_iibSP_EUliE_EEviiSP_T0_ f4d/common/base/BitUtil.h:186
    #8 0x7fdc35971fdd in _ZN8facebook3f4d4bits10forEachBitIZNKS0_4exec13VectorAdapterINS0_4core9UDFHolderINS0_9functions17udf_from_unixtime3udfINS3_10VectorExecEEESA_NS0_9TimestampEJdEEEE7iterateIJNS3_12VectorReaderIdvEEEEEvRNSE_12ApplyContextEbDpRKT_EUlT
yT_E_EEvPKmiibSO_ f4d/common/base/BitUtil.h:338                                                                                
    #9 0x7fdc35971a83 in _ZN8facebook3f4d4bits13forEachSetBitIZNKS0_4exec13VectorAdapterINS0_4core9UDFHolderINS0_9functions17udf_from_unixtime3udfINS3_10VectorExecEEESA_NS0_9TimestampEJdEEEE7iterateIJNS3_12VectorReaderIdvEEEEEvRNSE_12ApplyContextEbDpRKT_E
UlTyT_E_EEvPKmiiSO_ f4d/common/base/BitUtil.h:367
    #10 0x7fdc359707c5 in _ZNK8facebook3f4d17SelectivityVector15applyToSelectedIZNKS0_4exec13VectorAdapterINS0_4core9UDFHolderINS0_9functions17udf_from_unixtime3udfINS3_10VectorExecEEESA_NS0_9TimestampEJdEEEE7iterateIJNS3_12VectorReaderIdvEEEEEvRNSE_12App
lyContextEbDpRKT_EUlTyT_E_EEvSO_ f4d/vector/SelectivityVector.h:361
    #11 0x7fdc359701f4 in void facebook::f4d::exec::VectorAdapter<facebook::f4d::core::UDFHolder<facebook::f4d::functions::udf_from_unixtime::udf<facebook::f4d::exec::VectorExec>, facebook::f4d::exec::VectorExec, facebook::f4d::Timestamp, double> >::itera
te<facebook::f4d::exec::VectorReader<double, void> >(facebook::f4d::exec::VectorAdapter<facebook::f4d::core::UDFHolder<facebook::f4d::functions::udf_from_unixtime::udf<facebook::f4d::exec::VectorExec>, facebook::f4d::exec::VectorExec, facebook::f4d::Times
tamp, double> >::ApplyContext&, bool, facebook::f4d::exec::VectorReader<double, void> const&) const f4d/expression/VectorFunctionAdapter.h:133
    #12 0x7fdc3596fd92 in void facebook::f4d::exec::VectorAdapter<facebook::f4d::core::UDFHolder<facebook::f4d::functions::udf_from_unixtime::udf<facebook::f4d::exec::VectorExec>, facebook::f4d::exec::VectorExec, facebook::f4d::Timestamp, double> >::unpac
k<1, facebook::f4d::exec::VectorReader<double, void>, 0>(facebook::f4d::exec::VectorAdapter<facebook::f4d::core::UDFHolder<facebook::f4d::functions::udf_from_unixtime::udf<facebook::f4d::exec::VectorExec>, facebook::f4d::exec::VectorExec, facebook::f4d::T
imestamp, double> >::ApplyContext&, bool, facebook::f4d::exec::DecodedArgs const&, facebook::f4d::exec::VectorReader<double, void> const&) const f4d/expression/VectorFunctionAdapter.h:115
    #13 0x7fdc3596e6c6 in void facebook::f4d::exec::VectorAdapter<facebook::f4d::core::UDFHolder<facebook::f4d::functions::udf_from_unixtime::udf<facebook::f4d::exec::VectorExec>, facebook::f4d::exec::VectorExec, facebook::f4d::Timestamp, double> >::unpac
k<0, 0>(facebook::f4d::exec::VectorAdapter<facebook::f4d::core::UDFHolder<facebook::f4d::functions::udf_from_unixtime::udf<facebook::f4d::exec::VectorExec>, facebook::f4d::exec::VectorExec, facebook::f4d::Timestamp, double> >::ApplyContext&, bool, faceboo
k::f4d::exec::DecodedArgs const&) const f4d/expression/VectorFunctionAdapter.h:96
    #14 0x7fdc3596cdcd in facebook::f4d::exec::VectorAdapter<facebook::f4d::core::UDFHolder<facebook::f4d::functions::udf_from_unixtime::udf<facebook::f4d::exec::VectorExec>, facebook::f4d::exec::VectorExec, facebook::f4d::Timestamp, double> >::apply(face
book::f4d::SelectivityVector const&, std::vector<std::shared_ptr<facebook::f4d::BaseVector>, std::allocator<std::shared_ptr<facebook::f4d::BaseVector> > >&, facebook::f4d::exec::Expr*, facebook::f4d::exec::EvalCtx*, std::shared_ptr<facebook::f4d::BaseVect
or>*) const f4d/expression/VectorFunctionAdapter.h:69
    #15 0x7fdc34efa692 in facebook::f4d::exec::Expr::applyVectorFunction(facebook::f4d::SelectivityVector const&, facebook::f4d::exec::EvalCtx*, std::shared_ptr<facebook::f4d::BaseVector>*) f4d/expression/Expr.cpp:1026
    #16 0x7fdc34ef89d9 in facebook::f4d::exec::Expr::applyFunction(facebook::f4d::SelectivityVector const&, facebook::f4d::SelectivityVector const&, facebook::f4d::exec::EvalCtx*, std::shared_ptr<facebook::f4d::BaseVector>*) f4d/expression/Expr.cpp:1009
    #17 0x7fdc34eebc48 in facebook::f4d::exec::Expr::evalAll(facebook::f4d::SelectivityVector const&, facebook::f4d::exec::EvalCtx*, std::shared_ptr<facebook::f4d::BaseVector>*) f4d/expression/Expr.cpp:862
    #18 0x7fdc34ef4703 in facebook::f4d::exec::Expr::evalWithNulls(facebook::f4d::SelectivityVector const&, facebook::f4d::exec::EvalCtx*, std::shared_ptr<facebook::f4d::BaseVector>*) f4d/expression/Expr.cpp:654
    #19 0x7fdc34eed1cf in facebook::f4d::exec::Expr::evalEncodings(facebook::f4d::SelectivityVector const&, facebook::f4d::exec::EvalCtx*, std::shared_ptr<facebook::f4d::BaseVector>*) f4d/expression/Expr.cpp:580
    #20 0x7fdc34eeab83 in facebook::f4d::exec::Expr::eval(facebook::f4d::SelectivityVector const&, facebook::f4d::exec::EvalCtx*, std::shared_ptr<facebook::f4d::BaseVector>*) f4d/expression/Expr.cpp:251
    #21 0x7fdc34eeb6cc in facebook::f4d::exec::Expr::evalAll(facebook::f4d::SelectivityVector const&, facebook::f4d::exec::EvalCtx*, std::shared_ptr<facebook::f4d::BaseVector>*) f4d/expression/Expr.cpp:840
    #22 0x7fdc34ef4703 in facebook::f4d::exec::Expr::evalWithNulls(facebook::f4d::SelectivityVector const&, facebook::f4d::exec::EvalCtx*, std::shared_ptr<facebook::f4d::BaseVector>*) f4d/expression/Expr.cpp:654
    #23 0x7fdc34eed1cf in facebook::f4d::exec::Expr::evalEncodings(facebook::f4d::SelectivityVector const&, facebook::f4d::exec::EvalCtx*, std::shared_ptr<facebook::f4d::BaseVector>*) f4d/expression/Expr.cpp:580
    #24 0x7fdc34eeab83 in facebook::f4d::exec::Expr::eval(facebook::f4d::SelectivityVector const&, facebook::f4d::exec::EvalCtx*, std::shared_ptr<facebook::f4d::BaseVector>*) f4d/expression/Expr.cpp:251
    #25 0x7fdc34efcd6e in facebook::f4d::exec::ExprSet::eval(int, int, bool, facebook::f4d::SelectivityVector const&, facebook::f4d::exec::EvalCtx*, std::vector<std::shared_ptr<facebook::f4d::BaseVector>, std::allocator<std::shared_ptr<facebook::f4d::Base
Vector> > >*) f4d/expression/Expr.cpp:1114
    #26 0x2db31d in facebook::f4d::ExpressionExplorer::go() f4d/expression/tests/ExpressionExplorer.cpp:342

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    ๐Ÿ–– Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. ๐Ÿ“Š๐Ÿ“ˆ๐ŸŽ‰

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google โค๏ธ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.