RE: Increasing degree of parallelism when reading Parquet files

y questions/concerns. > > On Wed, Aug 11, 2021 at 1:24 AM Müller Ingo <mailto:ingo.muel...@inf.ethz.ch> > wrote: > > > Dear all, > > I have just tried out Wail's patch set from here: > https://issues.apache.org/jira/browse/ASTERIXDB-2945. It seem

RE: Increasing degree of parallelism when reading Parquet files

end of the week. > > On Tue, Aug 10, 2021 at 8:42 AM Müller Ingo <mailto:ingo.muel...@inf.ethz.ch> > wrote: > > > Let me also say that I can still rerun the experiments for the > (hopefully > subsequent) camera-ready version if the problem takes longer to fix

RE: Increasing degree of parallelism when reading Parquet files

Let me also say that I can still rerun the experiments for the (hopefully subsequent) camera-ready version if the problem takes longer to fix. Cheers, Ingo > -Original Message- > From: Müller Ingo > Sent: Tuesday, August 10, 2021 5:34 PM > To: users@asterixdb.apache.org &

RE: Increasing degree of parallelism when reading Parquet files

> Ingo, > > Got it! It sounds like we indeed have a parallelism performance bug in the > area > of threading for S3, then. Weird! We'll look into it... > > > Cheers, > > Mike > > > On 8/9/21 11:21 PM, Müller Ingo wrote: > > > Hey Mike,

RE: Increasing degree of parallelism when reading Parquet files

many parallel threads to > use > at the base of its query plans. (Obviously there is room for improvement on > that > behavior for use cases involving external storage. :-)) > > > Cheers, > > Mike > > > On 8/9/21 12:28 PM, Müller Ingo wrote: > > >

RE: Increasing degree of parallelism when reading Parquet files

ata to arrive. > > > On Mon, Aug 9, 2021 at 12:28 PM Müller Ingo <mailto:ingo.muel...@inf.ethz.ch> > wrote: > > > Hi Dmitry, > > Thanks a lot for checking! Indeed, my queries do not have an exchange. > However, the number of I/O devices has ind

RE: Increasing degree of parallelism when reading Parquet files

the first EXCHANGE operator. However, if your query doesn't have any > EXCHANGEs then it'll use the number of cores assigned for the initial data > scan > operator (number of I/O devices) > > Thanks, > -- Dmitry > > > On 8/9/21, 11:42 AM, "Müller Ingo&q

RE: Increasing degree of parallelism when reading Parquet files

m` "-1";) , > > or globally in the cluster configuration: > > https://github.com/apache/asterixdb/blob/master/asterixdb/asterix- > app/src/main/resources/cc2.conf#L57 > > > > Thanks, > > -- Dmitry > > > > > > From: Müller Ingo

Increasing degree of parallelism when reading Parquet files

Dear AsterixDB devs, I am currently trying out the new support for Parquet files on S3 (still in the context of my High-energy Physics use case [1]). This works great so far and has generally decent performance. However, I realized that it does not use more than 16 cores, even though 96

RE: Producing combinations of array elements in SQL++

Hey Mike, Thanks a lot for following up! I realize that one aspect wasn't very explicit in my description: I only want one permutation of each combination, e.g., I only want one pair out of (a1, a2) and (a2, a1). The Cartesian product contains both. In your example data, for "pkey": 2, I only

RE: Producing combinations of array elements in SQL++

se/ASTERIXDB-1052 > [3] https://issues.apache.org/jira/browse/ASTERIXDB-2595 (this one is > relevant > for array unnesting too) > > Thanks, > -- Dmitry > > > On 8/3/21, 10:20 AM, "Müller Ingo" wrote: > > EXTERNAL EMAIL: Use caution when opening

RE: Producing combinations of array elements in SQL++

p question: Is there an issue tracking the status of this feature? I couldn't find it in JIRA... Cheers, Ingo [6] https://github.com/RumbleDB/iris-hep-benchmark-sqlpp/commit/1023d97 > -Original Message- > From: Müller Ingo > Sent: Tuesday, August 3, 2021 6:03 PM > To: users@asterixdb.ap

RE: Producing combinations of array elements in SQL++

> > 2) As for window function calls. I can confirm that if there is no ORDER > BY sub-clause inside OVER clause then the order of the elements processed by > window functions (row_number(), rank(), etc) is not guaranteed. > > > > Thanks, > > --

RE: Git tags of latest 0.9.6 and 0.9.7

e confusion, > > - Ian > > On Tue, Aug 3, 2021 at 12:27 AM Müller Ingo wrote: > > > > Dear AsterixDB developers, > > > > > > > > I cannot find when the last two versions of AsterixDB were released. In > particular, I think that the

Producing combinations of array elements in SQL++

Dear SQL++ experts, I am working on an academic study [1] comparing the expressiveness of various query languages for nested data in a high-energy physics use case. Among other systems, I have implemented the queries of the use case in SQL++ [2]. In general, SQL++ seems to be quite well suited

Git tags of latest 0.9.6 and 0.9.7

Dear AsterixDB developers, I cannot find when the last two versions of AsterixDB were released. In particular, I think that the tags of these two versions are not on Github. If this is by mistake, could you push them there? Thanks and best regards, Ingo

RE: Testing for a type in SQL++

Dear all, Sorry, I overlooked the "built-in functions" page completely. There is my answer... All the best, Ingo > -Original Message- > From: Müller Ingo > Sent: Saturday, September 19, 2020 1:53 AM > To: 'users@asterixdb.apache.org' > Subject: Testing for