[GitHub] [drill] weijietong commented on issue #1838: DRILL-7341: Vector reAlloc may fails after exchange

[GitBox]

weijietong commented on issue #1838: DRILL-7341: Vector reAlloc may fails after 
exchange
URL: https://github.com/apache/drill/pull/1838#issuecomment-519762685
 
 
   LGTM +1


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.
 
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


With regards,
Apache Git Services

[GitHub] [drill] weijietong commented on a change in pull request #1838: DRILL-7341: Vector reAlloc may fails after exchange

[GitBox]

weijietong commented on a change in pull request #1838: DRILL-7341: Vector 
reAlloc may fails after exchange
URL: https://github.com/apache/drill/pull/1838#discussion_r312317242
 
 

 ##
 File path: exec/vector/src/main/codegen/templates/FixedValueVectors.java
 ##
 @@ -210,10 +210,16 @@ public void reAlloc() {
 // a zero-length buffer. Instead, just allocate a 256 byte
 // buffer if we start at 0.
 
-final long newAllocationSize = allocationSizeInBytes == 0
+long newAllocationSize = allocationSizeInBytes == 0
 ? 256
 : allocationSizeInBytes * 2L;
 
+// Some operations, such as Value Vector#exchange, can be change DrillBuf 
data field without corresponding allocation size changes.
+// Check that the size of the allocation is sufficient to copy the old 
buffer.
+while (newAllocationSize < data.capacity()) {
 
 Review comment:
   The change is to keep backward compatible. The reason I guess is that most 
of the fixed VV is number type. Initializing to zero is to keep the java 
default value convention.


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.
 
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


With regards,
Apache Git Services

Re: [DISCUSS]: Drill after MapR

[Ted Dunning]

Assuming that HPE won't support continued development is not warranted.
There is a risk in all change, but assuming the loss of support isn't
correct.

That said, the community should be able to release independently of any
single company, assuming that Apache has enough resources.


On Thu, Aug 8, 2019 at 9:49 AM Charles Givre  wrote:

> Hello all,
> Now that MapR is officially part of HPE, I wanted to ask everyone their
> thoughts about how we can continue to release Drill without the MapR owned
> infrastructure.  Assuming that HPE is not likely to continue supporting
> Drill (or maybe they will, but I'm guessing not) what infrastructure does
> the community need to take over?
> Can we start compiling a list and formulating a plan for this?
> Thanks,
> -- C

Re: [QUESTION]: Caching UDFs

[Igor Guzenko]

Hello Charles,

Although the idea seems good in general, actual implementation may cause
much more issues than solve. If you are thinking about distributed cache,
then every cache miss on current drillbit will cause network request to
other drillbits, passing function arguments along with ids of executable
query fragments. Local cache is more suitable of course, but another
problem may be that caching is actually great only for repeatable arguments
and especially when similar arguments are coming in one by one (like
presort rows by the args before function execution). For cases when args
are mostly distinct the caching will cause heavy memory overhead. But one
case when the caching may perform well is to know that rows are sorted by
function arguments and locally cache just one function call result for
bunch of repeated rows.  For example, suppose that we are executing query

*select x,y,* *slow_function(x,y) from (select x,y from dfs.`large_table`
order by x,y)*

*x y * *slow_function(x,y)*
1 1  (calculate and cache)
1 1  (get cached)
1 1  (get cached)
1 1  (get cached)
1 2  (calculate and cache)
1 2  (get cached)
1 2  (get cached)

in such case heavy logic in *slow_function(x,y)* will be executed only
twice for the rows.  But in this case ordering by x, y will most probably
kill all benefits provided by caching.

Thanks,
Igor

On Thu, Aug 8, 2019 at 7:46 PM Charles Givre 
wrote:

> Hello Drill Devs,
> I have a question about UDFs.  Let's say you have a non-trivial UDF called
> foo(x,y) which returns some value.  Assuming that if the arguments are the
> same, the function foo() will return the same result, does Drill have any
> optimizations to prevent running the non-trivial function?
>
> I was thinking that it might make sense to cache the arguments and results
> in memory and before the function is executed, check the cache to see if
> they're there.  If they are, return the cached results, and if not, execute
> the function.  I was thinking that for some functions, like date/time
> functions, we might want to include something in the code to ensure that
> the results do not get cached.
>
> Thoughts?
>
>
> Charles S. Givre CISSP
> Data Scientist,
> Co-Founder GTK Cyber LLC
>
> charles.gi...@gtkcyber.com
> *Mobile*: (443) 762-3286
>
>
> 
> 
>
>

[GitHub] [drill] kkhatua commented on a change in pull request #1779: DRILL-7222: Visualize estimated and actual row counts for a query

[GitBox]

kkhatua commented on a change in pull request #1779: DRILL-7222: Visualize 
estimated and actual row counts for a query
URL: https://github.com/apache/drill/pull/1779#discussion_r312214145
 
 

 ##
 File path: exec/java-exec/src/main/resources/rest/profile/profile.ftl
 ##
 @@ -587,6 +622,49 @@
   if (e.target.form) 
 <#if 
model.isOnlyImpersonationEnabled()>doSubmitQueryWithUserName()<#else>doSubmitQueryWithAutoLimit();
 });
+
+// Convert scientific to Decimal [Ref: 
https://gist.github.com/jiggzson/b5f489af9ad931e3d186]
+function scientificToDecimal(num) {
 
 Review comment:
   Yep. Verified it. Thanks for pointing it out.


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.
 
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


With regards,
Apache Git Services

Re: August Apache Drill board report

[Aman Sinha]

Thanks for putting this together Arina.  One minor comment is that for a
future release do we need to mention the feature set ?
Typically we would enumerate those in the next board report after the
release has happened.

Aman

On Thu, Aug 8, 2019 at 10:00 AM Sorabh Hamirwasia 
wrote:

> Hi Arina,
> Overall report looks good. One minor thing:
>  - Drill User Meetup was be held on May 22, 2019.
>
>
> Thanks,
>
> Sorabh
>
> On Thu, Aug 8, 2019 at 7:05 AM Arina Ielchiieva  wrote:
>
> > Hi all,
> >
> > please take a look at the draft board report for the last quarter and let
> > me know if you have any comments.
> >
> > Thanks,
> > Arina
> >
> > =
> >
> >  ## Description:
> >  - Drill is a Schema-free SQL Query Engine for Hadoop, NoSQL and Cloud
> >Storage.
> >
> > ## Issues:
> >  - There are no issues requiring board attention at this time.
> >
> > ## Activity:
> >  - Drill User Meetup was be held on May 22, 2019.
> >  - Drill 1.17.0 release is planned in the end of August / beginning
> > September,
> >it will include the following improvements:
> >- Drill Metastore implementation based on Iceberg tables and
> integration
> >- Hive arrays / structs support
> >- Canonical Map support
> >- Vararg UDFs support
> >- Run-time row group pruning
> >- Schema provisioning via table function
> >- Empty parquet files read / write support
> >
> > ## Health report:
> >  - Development activity is almost 50% down due to acquisition one of the
> > main Drill vendors.
> >  - Activity on the dev and user mailing lists is slightly down compared
> to
> > previous periods.
> >  - Four committers were added in the last period.
> >
> > ## PMC changes:
> >
> >  - Currently 24 PMC members.
> >  - No new PMC members added in the last 3 months
> >  - Last PMC addition was Sorabh Hamirwasia on Fri Apr 05 2019
> >
> > ## Committer base changes:
> >
> >  - Currently 55 committers.
> >  - New commmitters:
> > - Anton Gozhiy was added as a committer on Mon Jul 22 2019
> > - Bohdan Kazydub was added as a committer on Mon Jul 15 2019
> > - Igor Guzenko was added as a committer on Mon Jul 22 2019
> > - Venkata Jyothsna Donapati was added as a committer on Mon May 13
> 2019
> >
> > ## Releases:
> >
> >  - Last release was 1.16.0 on Thu May 02 2019
> >
> > ## Mailing list activity:
> >
> >  - dev@drill.apache.org:
> > - 403 subscribers (down -5 in the last 3 months):
> > - 1156 emails sent to list ( in previous quarter)
> >
> >  - iss...@drill.apache.org:
> > - 17 subscribers (up 0 in the last 3 months):
> > - 1496 emails sent to list (2315 in previous quarter)
> >
> >  - u...@drill.apache.org:
> > - 575 subscribers (down -6 in the last 3 months):
> > - 157 emails sent to list (230 in previous quarter)
> >
> > ## JIRA activity:
> >
> >  - 96 JIRA tickets created in the last 3 months
> >  - 68 JIRA tickets closed/resolved in the last 3 months
> >
>

Re: [DISCUSS]: Drill after MapR

[Paul Rogers]

Hi Charles,

Thanks for raising this issue.

The short answer is probably "the cloud." The longer answer should include:

* Who will manage the AWS/GCE instances?

* Who will pay for the instances?

* The MapR infrastructure uses the MapR file system and Hadoop distro. Probably 
should use Hadoop (or EMR) for Apache. Who will do the port?

* The test framework itself is public in the MapR Github repo [1]. Perhaps it 
should migrate to the Apache Drill repo?

* The tests are run within MapR using a very nice Jenkins job that Abhishek 
created. How can we make this public and port it to the cloud?

We might look at what Impala did. Cloudera hosts a pubic build system: anyone 
can submit a build job (though the jobs are throttled, etc.)

Thanks,
- Paul

[1] https://github.com/mapr/drill-test-framework


 

On Thursday, August 8, 2019, 09:49:42 AM PDT, Charles Givre 
 wrote:  
 
 Hello all, 
Now that MapR is officially part of HPE, I wanted to ask everyone their 
thoughts about how we can continue to release Drill without the MapR owned 
infrastructure.  Assuming that HPE is not likely to continue supporting Drill 
(or maybe they will, but I'm guessing not) what infrastructure does the 
community need to take over?
Can we start compiling a list and formulating a plan for this?
Thanks,
-- C  

Re: August Apache Drill board report

[Sorabh Hamirwasia]

Hi Arina,
Overall report looks good. One minor thing:
 - Drill User Meetup was be held on May 22, 2019.


Thanks,

Sorabh

On Thu, Aug 8, 2019 at 7:05 AM Arina Ielchiieva  wrote:

> Hi all,
>
> please take a look at the draft board report for the last quarter and let
> me know if you have any comments.
>
> Thanks,
> Arina
>
> =
>
>  ## Description:
>  - Drill is a Schema-free SQL Query Engine for Hadoop, NoSQL and Cloud
>Storage.
>
> ## Issues:
>  - There are no issues requiring board attention at this time.
>
> ## Activity:
>  - Drill User Meetup was be held on May 22, 2019.
>  - Drill 1.17.0 release is planned in the end of August / beginning
> September,
>it will include the following improvements:
>- Drill Metastore implementation based on Iceberg tables and integration
>- Hive arrays / structs support
>- Canonical Map support
>- Vararg UDFs support
>- Run-time row group pruning
>- Schema provisioning via table function
>- Empty parquet files read / write support
>
> ## Health report:
>  - Development activity is almost 50% down due to acquisition one of the
> main Drill vendors.
>  - Activity on the dev and user mailing lists is slightly down compared to
> previous periods.
>  - Four committers were added in the last period.
>
> ## PMC changes:
>
>  - Currently 24 PMC members.
>  - No new PMC members added in the last 3 months
>  - Last PMC addition was Sorabh Hamirwasia on Fri Apr 05 2019
>
> ## Committer base changes:
>
>  - Currently 55 committers.
>  - New commmitters:
> - Anton Gozhiy was added as a committer on Mon Jul 22 2019
> - Bohdan Kazydub was added as a committer on Mon Jul 15 2019
> - Igor Guzenko was added as a committer on Mon Jul 22 2019
> - Venkata Jyothsna Donapati was added as a committer on Mon May 13 2019
>
> ## Releases:
>
>  - Last release was 1.16.0 on Thu May 02 2019
>
> ## Mailing list activity:
>
>  - dev@drill.apache.org:
> - 403 subscribers (down -5 in the last 3 months):
> - 1156 emails sent to list ( in previous quarter)
>
>  - iss...@drill.apache.org:
> - 17 subscribers (up 0 in the last 3 months):
> - 1496 emails sent to list (2315 in previous quarter)
>
>  - u...@drill.apache.org:
> - 575 subscribers (down -6 in the last 3 months):
> - 157 emails sent to list (230 in previous quarter)
>
> ## JIRA activity:
>
>  - 96 JIRA tickets created in the last 3 months
>  - 68 JIRA tickets closed/resolved in the last 3 months
>

Re: [QUESTION]: Caching UDFs

[Paul Rogers]

Hi Charles,

In general, we cannot know if a function is deterministic. Your function might 
be rand(seed, max). It might do a JDBC lookup or a REST call. Drill can't know 
(unless we add some way to know that a function is deterministic: maybe a 
@Deterministic annotation.)

That said, you can build in caching inside the function. Should your cache be 
separate from mine for security reasons? Should the cache be shared across 
execution threads on a given node? Local to a single minor fragment?

Aggregates are example of functions that have internal state, perhaps the idea 
can be extended for a function-specific results cache.

Thanks,
- Paul

 

On Thursday, August 8, 2019, 09:46:12 AM PDT, Charles Givre 
 wrote:  
 
 Hello Drill Devs,I have a question about UDFs.  Let's say you have a 
non-trivial UDF called foo(x,y) which returns some value.  Assuming that if the 
arguments are the same, the function foo() will return the same result, does 
Drill have any optimizations to prevent running the non-trivial function?  
I was thinking that it might make sense to cache the arguments and results in 
memory and before the function is executed, check the cache to see if they're 
there.  If they are, return the cached results, and if not, execute the 
function.  I was thinking that for some functions, like date/time functions, we 
might want to include something in the code to ensure that the results do not 
get cached. 
Thoughts?

Charles S. Givre CISSPData Scientist, Co-Founder GTK Cyber LLC
charles.givre@gtkcyber.comMobile: (443) 762-3286


  

[DISCUSS]: Drill after MapR

[Charles Givre]

Hello all, 
Now that MapR is officially part of HPE, I wanted to ask everyone their 
thoughts about how we can continue to release Drill without the MapR owned 
infrastructure.  Assuming that HPE is not likely to continue supporting Drill 
(or maybe they will, but I'm guessing not) what infrastructure does the 
community need to take over?
Can we start compiling a list and formulating a plan for this?
Thanks,
-- C

[QUESTION]: Caching UDFs

[Charles Givre]

Hello Drill Devs,
I have a question about UDFs.  Let's say you have a non-trivial UDF called 
foo(x,y) which returns some value.  Assuming that if the arguments are the 
same, the function foo() will return the same result, does Drill have any 
optimizations to prevent running the non-trivial function?  

I was thinking that it might make sense to cache the arguments and results in 
memory and before the function is executed, check the cache to see if they're 
there.  If they are, return the cached results, and if not, execute the 
function.  I was thinking that for some functions, like date/time functions, we 
might want to include something in the code to ensure that the results do not 
get cached. 

Thoughts?


Charles S. Givre CISSP
Data Scientist, 
Co-Founder GTK Cyber LLC

charles.gi...@gtkcyber.com
Mobile: (443) 762-3286


 
 

[jira] [Resolved] (DRILL-7321) split function doesn't work without from

[Volodymyr Vysotskyi (JIRA)]

 [ 
https://issues.apache.org/jira/browse/DRILL-7321?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Volodymyr Vysotskyi resolved DRILL-7321.

   Resolution: Fixed
Fix Version/s: 1.17.0

Fixed in the sope of DRILL-7337.

> split function doesn't work without from
> 
>
> Key: DRILL-7321
> URL: https://issues.apache.org/jira/browse/DRILL-7321
> Project: Apache Drill
>  Issue Type: Bug
>  Components: Functions - Drill
>Affects Versions: 1.16.0
>Reporter: benj
>Assignee: Volodymyr Vysotskyi
>Priority: Minor
> Fix For: 1.17.0
>
>
> {code:java}
> SELECT upper('foo') AS a /* OK */;
> +-+
> |  a  |
> +-+
> | foo |
> +-+
> {code}
> but
> {code:java}
> SELECT split('foo,bar,buz',',') AS a /* NOK */;
> Error: PLAN ERROR: Failure while materializing expression in constant 
> expression evaluator [SPLIT('foo,bar,buz', ',')].  Errors:
> Error in expression at index -1.  Error: Only ProjectRecordBatch could have 
> complex writer function. You are using complex writer function split in a 
> non-project operation!.  Full expression: --UNKNOWN EXPRESSION--.{code}
> Note that
> {code:java}
> SELECT split(a,',') AS a FROM (SELECT 'foo,bar,buz' AS a) /* OK */;
> +-+
> |  a  |
> +-+
> | ["foo","bar","buz"] |
> +-+
> {code}
>  



--
This message was sent by Atlassian JIRA
(v7.6.14#76016)

August Apache Drill board report

[Arina Ielchiieva]

Hi all,

please take a look at the draft board report for the last quarter and let
me know if you have any comments.

Thanks,
Arina

=

 ## Description:
 - Drill is a Schema-free SQL Query Engine for Hadoop, NoSQL and Cloud
   Storage.

## Issues:
 - There are no issues requiring board attention at this time.

## Activity:
 - Drill User Meetup was be held on May 22, 2019.
 - Drill 1.17.0 release is planned in the end of August / beginning
September,
   it will include the following improvements:
   - Drill Metastore implementation based on Iceberg tables and integration
   - Hive arrays / structs support
   - Canonical Map support
   - Vararg UDFs support
   - Run-time row group pruning
   - Schema provisioning via table function
   - Empty parquet files read / write support

## Health report:
 - Development activity is almost 50% down due to acquisition one of the
main Drill vendors.
 - Activity on the dev and user mailing lists is slightly down compared to
previous periods.
 - Four committers were added in the last period.

## PMC changes:

 - Currently 24 PMC members.
 - No new PMC members added in the last 3 months
 - Last PMC addition was Sorabh Hamirwasia on Fri Apr 05 2019

## Committer base changes:

 - Currently 55 committers.
 - New commmitters:
- Anton Gozhiy was added as a committer on Mon Jul 22 2019
- Bohdan Kazydub was added as a committer on Mon Jul 15 2019
- Igor Guzenko was added as a committer on Mon Jul 22 2019
- Venkata Jyothsna Donapati was added as a committer on Mon May 13 2019

## Releases:

 - Last release was 1.16.0 on Thu May 02 2019

## Mailing list activity:

 - dev@drill.apache.org:
- 403 subscribers (down -5 in the last 3 months):
- 1156 emails sent to list ( in previous quarter)

 - iss...@drill.apache.org:
- 17 subscribers (up 0 in the last 3 months):
- 1496 emails sent to list (2315 in previous quarter)

 - u...@drill.apache.org:
- 575 subscribers (down -6 in the last 3 months):
- 157 emails sent to list (230 in previous quarter)

## JIRA activity:

 - 96 JIRA tickets created in the last 3 months
 - 68 JIRA tickets closed/resolved in the last 3 months

[GitHub] [drill] oleg-zinovev commented on a change in pull request #1838: DRILL-7341: Vector reAlloc may fails after exchange

[GitBox]

oleg-zinovev commented on a change in pull request #1838: DRILL-7341: Vector 
reAlloc may fails after exchange
URL: https://github.com/apache/drill/pull/1838#discussion_r311989195
 
 

 ##
 File path: exec/vector/src/main/codegen/templates/FixedValueVectors.java
 ##
 @@ -210,10 +210,16 @@ public void reAlloc() {
 // a zero-length buffer. Instead, just allocate a 256 byte
 // buffer if we start at 0.
 
-final long newAllocationSize = allocationSizeInBytes == 0
+long newAllocationSize = allocationSizeInBytes == 0
 ? 256
 : allocationSizeInBytes * 2L;
 
+// Some operations, such as Value Vector#exchange, can be change DrillBuf 
data field without corresponding allocation size changes.
+// Check that the size of the allocation is sufficient to copy the old 
buffer.
+while (newAllocationSize < data.capacity()) {
 
 Review comment:
   Done.
   
   Could you clarify why DrillBuf#setZero performed only for FixedValueVectors?


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.
 
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


With regards,
Apache Git Services

[GitHub] [drill] oleg-zinovev commented on a change in pull request #1838: DRILL-7341: Vector reAlloc may fails after exchange

[GitBox]

oleg-zinovev commented on a change in pull request #1838: DRILL-7341: Vector 
reAlloc may fails after exchange
URL: https://github.com/apache/drill/pull/1838#discussion_r311989195
 
 

 ##
 File path: exec/vector/src/main/codegen/templates/FixedValueVectors.java
 ##
 @@ -210,10 +210,16 @@ public void reAlloc() {
 // a zero-length buffer. Instead, just allocate a 256 byte
 // buffer if we start at 0.
 
-final long newAllocationSize = allocationSizeInBytes == 0
+long newAllocationSize = allocationSizeInBytes == 0
 ? 256
 : allocationSizeInBytes * 2L;
 
+// Some operations, such as Value Vector#exchange, can be change DrillBuf 
data field without corresponding allocation size changes.
+// Check that the size of the allocation is sufficient to copy the old 
buffer.
+while (newAllocationSize < data.capacity()) {
 
 Review comment:
   Done.
   
   Could you clarify why DrillBug#setZero performed only for FixedValueVectors?


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.
 
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


With regards,
Apache Git Services

[GitHub] [drill] vvysotskyi merged pull request #1835: DRILL-7337: Add vararg UDFs support

[GitBox]

vvysotskyi merged pull request #1835: DRILL-7337: Add vararg UDFs support
URL: https://github.com/apache/drill/pull/1835
 
 
   


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.
 
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


With regards,
Apache Git Services

[GitHub] [drill] agozhiy commented on issue #1779: DRILL-7222: Visualize estimated and actual row counts for a query

[GitBox]

agozhiy commented on issue #1779: DRILL-7222: Visualize estimated and actual 
row counts for a query
URL: https://github.com/apache/drill/pull/1779#issuecomment-519473200
 
 
   @kkhatua, thank you for the changes, please answer just a few more comments 
I left in conversations.


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.
 
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


With regards,
Apache Git Services

[GitHub] [drill] agozhiy commented on a change in pull request #1779: DRILL-7222: Visualize estimated and actual row counts for a query

[GitBox]

agozhiy commented on a change in pull request #1779: DRILL-7222: Visualize 
estimated and actual row counts for a query
URL: https://github.com/apache/drill/pull/1779#discussion_r311958036
 
 

 ##
 File path: exec/java-exec/src/main/resources/rest/profile/profile.ftl
 ##
 @@ -587,6 +622,49 @@
   if (e.target.form) 
 <#if 
model.isOnlyImpersonationEnabled()>doSubmitQueryWithUserName()<#else>doSubmitQueryWithAutoLimit();
 });
+
+// Convert scientific to Decimal [Ref: 
https://gist.github.com/jiggzson/b5f489af9ad931e3d186]
+function scientificToDecimal(num) {
 
 Review comment:
   From the Chrome web console:
   `> parseInt(1.6E7)`
   `< 1600`
   So it works it seems.
   Update: as you use Number(), this is not needed all the more.


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.
 
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


With regards,
Apache Git Services

[GitHub] [drill] agozhiy commented on a change in pull request #1779: DRILL-7222: Visualize estimated and actual row counts for a query

[GitBox]

agozhiy commented on a change in pull request #1779: DRILL-7222: Visualize 
estimated and actual row counts for a query
URL: https://github.com/apache/drill/pull/1779#discussion_r311966621
 
 

 ##
 File path: exec/java-exec/src/main/resources/rest/profile/profile.ftl
 ##
 @@ -84,6 +84,29 @@
 document.getElementById(warningElemId).style.display="none";
 }
 
+//Injects Estimated Rows
+function injectEstimatedRows() {
+  Object.keys(opRowCountMap).forEach(key => {
+var tgtElem = $("td.estRowsAnchor[key='"+key+"']"); 
+var status = tgtElem.append( "("+opRowCountMap[key]+")" );
 
 Review comment:
   Spaces are still present around the expression inside parentheses. This is 
inconsistent with the overall code style. 


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.
 
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


With regards,
Apache Git Services

[GitHub] [drill] arina-ielchiieva commented on issue #1837: DRILL-7338: REST API calls to Drill fail due to insufficient heap memory

[GitBox]

arina-ielchiieva commented on issue #1837: DRILL-7338: REST API calls to Drill 
fail due to insufficient heap memory
URL: https://github.com/apache/drill/pull/1837#issuecomment-519458040
 
 
   +1, please squash the commits.


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.
 
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


With regards,
Apache Git Services

[GitHub] [drill] agozhiy commented on a change in pull request #1779: DRILL-7222: Visualize estimated and actual row counts for a query

[GitBox]

agozhiy commented on a change in pull request #1779: DRILL-7222: Visualize 
estimated and actual row counts for a query
URL: https://github.com/apache/drill/pull/1779#discussion_r311958036
 
 

 ##
 File path: exec/java-exec/src/main/resources/rest/profile/profile.ftl
 ##
 @@ -587,6 +622,49 @@
   if (e.target.form) 
 <#if 
model.isOnlyImpersonationEnabled()>doSubmitQueryWithUserName()<#else>doSubmitQueryWithAutoLimit();
 });
+
+// Convert scientific to Decimal [Ref: 
https://gist.github.com/jiggzson/b5f489af9ad931e3d186]
+function scientificToDecimal(num) {
 
 Review comment:
   From the Chrome web console:
   `> parseInt(1.6E7)`
   `< 1600`
   So it works it seems.


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.
 
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


With regards,
Apache Git Services

[GitHub] [drill] agozhiy commented on a change in pull request #1779: DRILL-7222: Visualize estimated and actual row counts for a query

[GitBox]

agozhiy commented on a change in pull request #1779: DRILL-7222: Visualize 
estimated and actual row counts for a query
URL: https://github.com/apache/drill/pull/1779#discussion_r311953200
 
 

 ##
 File path: exec/java-exec/src/main/resources/rest/profile/profile.ftl
 ##
 @@ -587,6 +622,49 @@
   if (e.target.form) 
 <#if 
model.isOnlyImpersonationEnabled()>doSubmitQueryWithUserName()<#else>doSubmitQueryWithAutoLimit();
 });
+
+// Convert scientific to Decimal [Ref: 
https://gist.github.com/jiggzson/b5f489af9ad931e3d186]
+function scientificToDecimal(num) {
+  //if the number is in scientific notation remove it
+  if(/\d+\.?\d*e[\+\-]*\d+/i.test(num)) {
+var zero = '0',
+parts = String(num).toLowerCase().split('e'), //split into coeff 
and exponent
+e = parts.pop(),//store the exponential part
+l = Math.abs(e), //get the number of zeros
+sign = e/l,
+coeff_array = parts[0].split('.');
+if(sign === -1) {
+coeff_array[0] = Math.abs(coeff_array[0]);
+num = '-'+zero + '.' + new Array(l).join(zero) + 
coeff_array.join('');
+}
+else {
+var dec = coeff_array[1];
+if(dec) l = l - dec.length;
+num = coeff_array.join('') + new Array(l+1).join(zero);
+}
+  }
+  return num;
+}
+
+// Extract estimated rowcount map
+var opRowCountMap = {};
+// Get OpId-Rowocunt Map
+function buildRowCountMap() {
+  var phyText = $('#query-physical').find('pre').text();
+  var opLines = phyText.split("\n");
+  for (var l in opLines) {
+var line = opLines[l];
+if (line.trim().length > 0) {
+  var opId = line.match(/\d+-\d+/g)[0];
+  var opRowCount = line.match(/rowcount = \S+/g)[0].split(' 
')[2].replace(',','').trim();
 
 Review comment:
   Right. Still, it can be simplified. This should work with both formats:
   `line.match(/rowcount = ([^,]+)/)[1]`


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.
 
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


With regards,
Apache Git Services