[jira] [Commented] (DRILL-6115) SingleMergeExchange is not scaling up when many minor fragments are allocated for a query.

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/DRILL-6115?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16351858#comment-16351858
 ] 

ASF GitHub Bot commented on DRILL-6115:
---

GitHub user HanumathRao opened a pull request:

https://github.com/apache/drill/pull/1110

DRILL-6115: SingleMergeExchange is not scaling up when many minor fra…

…gments are allocated for a query.

Currently a singlemerge exchange is merging all the fragment streams on 
foreman. This can cause cpu bottleneck and also huge memory consumption at the 
foreman. 

This PR contains changes to introduce a new Multiplex Operator called 
OrderedMuxExchange which merges the minor fragment streams pertaining to one 
drillbit and send as one output stream to the foreman. 

The existing multiplex mechanism is used to introduce these operators.

Please review this PR.

You can merge this pull request into a Git repository by running:

$ git pull https://github.com/HanumathRao/drill DRILL-6115

Alternatively you can review and apply these changes as the patch at:

https://github.com/apache/drill/pull/1110.patch

To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:

This closes #1110


commit 43a71277aeec9bb377181728b2ce563437d7e46d
Author: hmaduri 
Date:   2018-01-22T00:42:28Z

DRILL-6115: SingleMergeExchange is not scaling up when many minor fragments 
are allocated for a query.




> SingleMergeExchange is not scaling up when many minor fragments are allocated 
> for a query.
> --
>
> Key: DRILL-6115
> URL: https://issues.apache.org/jira/browse/DRILL-6115
> Project: Apache Drill
>  Issue Type: Improvement
>  Components: Execution - Relational Operators
>Affects Versions: 1.12.0
>Reporter: Hanumath Rao Maduri
>Assignee: Hanumath Rao Maduri
>Priority: Major
> Fix For: 1.13.0
>
> Attachments: Enhancing Drill to multiplex ordered merge exchanges.docx
>
>
> SingleMergeExchange is created when a global order is required in the output. 
> The following query produces the SingleMergeExchange.
> {code:java}
> 0: jdbc:drill:zk=local> explain plan for select L_LINENUMBER from 
> dfs.`/drill/tables/lineitem` order by L_LINENUMBER;
> +--+--+
> | text | json |
> +--+--+
> | 00-00 Screen
> 00-01 Project(L_LINENUMBER=[$0])
> 00-02 SingleMergeExchange(sort0=[0])
> 01-01 SelectionVectorRemover
> 01-02 Sort(sort0=[$0], dir0=[ASC])
> 01-03 HashToRandomExchange(dist0=[[$0]])
> 02-01 Scan(table=[[dfs, /drill/tables/lineitem]], 
> groupscan=[JsonTableGroupScan [ScanSpec=JsonScanSpec 
> [tableName=maprfs:///drill/tables/lineitem, condition=null], 
> columns=[`L_LINENUMBER`], maxwidth=15]])
> {code}
> On a 10 node cluster if the table is huge then DRILL can spawn many minor 
> fragments which are all merged on a single node with one merge receiver. 
> Doing so will create lot of memory pressure on the receiver node and also 
> execution bottleneck. To address this issue, merge receiver should be 
> multiphase merge receiver. 
> Ideally for large cluster one can introduce tree merges so that merging can 
> be done parallel. But as a first step I think it is better to use the 
> existing infrastructure for multiplexing operators to generate an OrderedMux 
> so that all the minor fragments pertaining to one DRILLBIT should be merged 
> and the merged data can be sent across to the receiver operator.
> On a 10 node cluster if each node processes 14 minor fragments.
> Current version of code merges 140 minor fragments
> the proposed version has two level merges 1 - 14 merge in each drillbit which 
> is parallel 
> and 10 minorfragments are merged at the receiver node.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (DRILL-6116) MAXDIR - Unsupported operation exception // partition explorer interface?

[Kunal Khatua (JIRA)]

[ 
https://issues.apache.org/jira/browse/DRILL-6116?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16351942#comment-16351942
 ] 

Kunal Khatua commented on DRILL-6116:
-

Can you share the JSON profiles generated for both the queries?

> MAXDIR - Unsupported operation exception // partition explorer interface?
> -
>
> Key: DRILL-6116
> URL: https://issues.apache.org/jira/browse/DRILL-6116
> Project: Apache Drill
>  Issue Type: Bug
>  Components: Client - JDBC
>Affects Versions: 1.10.0
>Reporter: John Humphreys
>Priority: Major
>
> Using MAXDIR in drill seems to cause errors when trying to apply other 
> standard where clause filters. Am I doing something wrong here?
> **This Query Fails**
> SELECT epoch_hour, entity, `1_average`, `1_95p`
>  FROM dfs.`/path/drill-hour-final/`
>  where
>  dir0 = '2018' and dir1 = '01' and dir2 = '27'
>  and dir3 = MAXDIR('dfs', concat('/path/drill-hour-final/',
>  dir0, '/', dir1, '/', dir2, '/')) 
>  and entity = 1784928
> **With This Error**
> > SYSTEM ERROR: UnsupportedOperationException: The partition explorer
> > interface can only be used in functions that can be evaluated at
> > planning time. Make sure that the planner.enable_constant_folding
> > configuration option is set to true.
> > 
> > Fragment 1:7
> > 
> > [Error Id: d62c8227-db0e-4d31-9443-e570193d1010 on
> > psclxcpdevsys13.nomura.com:31010]
> **Wrapping it Makes it Work Without Error**
> select * from (
>  SELECT epoch_hour, entity, `1_average`, `1_95p`
>  FROM dfs.`/path/drill-hour-final/`
>  where
>  dir0 = '2018' and dir1 = '01' and dir2 = '27'
>  and dir3 = MAXDIR('dfs', concat('/path/drill-hour-final/',
>  dir0, '/', dir1, '/', dir2, '/'))
>  ) where entity = 1784928
> epoch_hour entity 1_average 1_95p
>  1517086800 1784928 5.3347222 8.82857142857143
>  1517014800 1784928 25.944984717977217 40.37453087409783



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (DRILL-6107) NullPointerException while querying MongoDB collection

[Kunal Khatua (JIRA)]

[ 
https://issues.apache.org/jira/browse/DRILL-6107?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16351971#comment-16351971
 ] 

Kunal Khatua commented on DRILL-6107:
-

Did you try enclosing the word with accent quotes? 
{code:sql}
select `ports` from mongo.ivre.hosts;
{code}

> NullPointerException while querying MongoDB collection
> --
>
> Key: DRILL-6107
> URL: https://issues.apache.org/jira/browse/DRILL-6107
> Project: Apache Drill
>  Issue Type: Bug
>  Components:  Server
>Affects Versions: 1.11.0, 1.12.0
> Environment: Drill specific
> {noformat}
> export DRILL_HEAP=${DRILL_HEAP:-"1G"}
> export DRILL_MAX_DIRECT_MEMORY=${DRILL_MAX_DIRECT_MEMORY:-"2G"}
> {noformat}
> Other
> {noformat}
> Memory: 8 GiB
> Processor: 2 VCPU (Intel i7)
> Disk: 19 GiB (13 GiB free)
> OS: Ubuntu 16.06
> Java: OpenJDK 1.8.0_151
> {noformat}
>Reporter: Duarte Silva
>Priority: Major
> Attachments: collection.bson.log, drillbit.log
>
>
> I have installed Drill and configured it to connect to a MongoDB instance. 
> That instance as a collection with a single document. When I query that 
> collection using:
> {code:sql}
> select ports from mongo.ivre.hosts;{code}
> It fails with a NullPointerException. I'm able to query that collection as 
> long as I don't select the "ports" property. Looking at the exception stack 
> trace and respective Drill code it is clear that the "map" variable isn't 
> suppose to be "null".
> {code:java}
> public MapOrListWriter list(final String name) {
>   assert map != null;
>   return new MapOrListWriterImpl(map.list(name));
> }
> {code}
> I couldn't figure out why it wasn't being initialized. I have attached the 
> log and the collection BSON file. Thanks in advance.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (DRILL-6105) SYSTEM ERROR: NullPointerException

[Kunal Khatua (JIRA)]

[ 
https://issues.apache.org/jira/browse/DRILL-6105?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16351974#comment-16351974
 ] 

Kunal Khatua commented on DRILL-6105:
-

Could you share more details about the setup, like Hive version, platform, etc. 
? I take it you don't hit this issue with the older Drill 1.8.0 version.

> SYSTEM ERROR: NullPointerException
> --
>
> Key: DRILL-6105
> URL: https://issues.apache.org/jira/browse/DRILL-6105
> Project: Apache Drill
>  Issue Type: Bug
>  Components: Execution - Flow
>Affects Versions: 1.12.0
>Reporter: Nitin Pawar
>Priority: Critical
>
> We just upgraded drill from 1.8.0 to 1.12.0
> One of the issue which left us behind was whenever we upgraded Drill we were 
> hit will null pointer exception in scenario which we could not spend time 
> debugging. Then we rolled back to 1.8.0
> This time we have spent some time and understood the problem
>  
> data set: 3 million records
> 5 columns, 2 of which are date columns (Let us call these date columns as A 
> and B)
> In column B majority of the values are nulls (roughly 99.5%)
> our query is select * from table where A = B
> above query fails with null pointer exception where the number of underlying 
> parquet files are more than 1. If I merge the underlying parquet files into a 
> single large file then we do not see this issue. 
> We also were able to remove the error if we changed the where clause with 
> coalesce(A,null) = coalesce(B,null)
> This somehow points us that the error is coming while reading the parquet 
> files with the given data types.
>  



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Assigned] (DRILL-6095) Drill PStore HBase doc shows 4 zookeepers in quorum, fix to 3 or 5 as per standard practice

[Kunal Khatua (JIRA)]

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

Kunal Khatua reassigned DRILL-6095:
---

Assignee: Bridget Bevens

> Drill PStore HBase doc shows 4 zookeepers in quorum, fix to 3 or 5 as per 
> standard practice
> ---
>
> Key: DRILL-6095
> URL: https://issues.apache.org/jira/browse/DRILL-6095
> Project: Apache Drill
>  Issue Type: Improvement
>  Components: Documentation
>Affects Versions: 1.12.0
> Environment: MapR 5.2
>  
>Reporter: Hari Sekhon
>Assignee: Bridget Bevens
>Priority: Trivial
>
> Drill's documentation on PStore configuration to HBase shows sample config 
> with 4 ZooKeeper ip addresses in the {{hbase.zookeeper.quorum field}}, this 
> should be fixed to 3 or 5 as per ZooKeeper best practices.
> [https://drill.apache.org/docs/persistent-configuration-storage/]



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Updated] (DRILL-6103) lsb_release: command not found

[Kunal Khatua (JIRA)]

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

Kunal Khatua updated DRILL-6103:

Fix Version/s: 1.13.0

> lsb_release: command not found
> --
>
> Key: DRILL-6103
> URL: https://issues.apache.org/jira/browse/DRILL-6103
> Project: Apache Drill
>  Issue Type: Bug
>Reporter: Chunhui Shi
>Priority: Major
> Fix For: 1.13.0
>
>
> Got this error when running drillbit.sh:
>  
> $ bin/drillbit.sh restart
> bin/drill-config.sh: line 317: lsb_release: command not found



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (DRILL-6103) lsb_release: command not found

[Kunal Khatua (JIRA)]

[ 
https://issues.apache.org/jira/browse/DRILL-6103?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16351976#comment-16351976
 ] 

Kunal Khatua commented on DRILL-6103:
-

Which platform is this? {{lsb_release}} should work in the Linux environment 
IMO.

https://github.com/apache/drill/blob/master/distribution/src/resources/drill-config.sh#L317

> lsb_release: command not found
> --
>
> Key: DRILL-6103
> URL: https://issues.apache.org/jira/browse/DRILL-6103
> Project: Apache Drill
>  Issue Type: Bug
>Reporter: Chunhui Shi
>Priority: Major
> Fix For: 1.13.0
>
>
> Got this error when running drillbit.sh:
>  
> $ bin/drillbit.sh restart
> bin/drill-config.sh: line 317: lsb_release: command not found



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (DRILL-6091) Continued Validation Error - Replacing Tables

[Kunal Khatua (JIRA)]

[ 
https://issues.apache.org/jira/browse/DRILL-6091?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16351977#comment-16351977
 ] 

Kunal Khatua commented on DRILL-6091:
-

Hi [~BSpinn] 

What was the solution for this resolving this?

> Continued Validation Error - Replacing Tables
> -
>
> Key: DRILL-6091
> URL: https://issues.apache.org/jira/browse/DRILL-6091
> Project: Apache Drill
>  Issue Type: Bug
>Reporter: Brandi Spinn
>Priority: Major
>
> We are currently running a project which is utilizing the Drill push to 
> Tableau function to be able to work with our data sets, we are already 
> working with Tableau regarding our needs and determined that this is our best 
> course of action considering how large data sets are - over 2 million rows 
> per day.
>  
> At the moment we have several visualizations we have published, but we are 
> running in an issue each morning where some of them are not updating 
> according to our schedules, and when we review the logs we find some the same 
> type of "fatal" errors that do not always allow the visualizations to update. 
> We also continually run into "drill server down" errors.
>  
> I have reached out to our account rep through Tableau for possible guidance, 
> however, they have indicated that it is not an issue on the Tableau side - 
> which we figured.
>  
> Below is a sample of the error codes we are seeing, please let me know you 
> are able to assist or if you need any additional information. Thank you!
>  
> |_Auto_AOD_Content:288 - create table dfs.tmp.attributes as select distinct 
> channels.marketingname as channelmarketingname, channels.streamingname as 
> channelstreamingname, channels.channelguid as channelGuid, channels.channelid 
> as channelId, categories.category_name as channelcategory, CASE when 
> music.channel_guid is not null then 'Music' else null end as genre_Music, 
> CASE when news.channel_guid is not null then 'News' else null end as 
> genre_News, CASE when sports.channel_guid is not null then 'Sports' else null 
> end as genre_Sports,  CASE when talk.channel_guid is not null then 'Talk' 
> else null end as genre_Talk, CASE when howard.channel_guid is not null then 
> 'Howard' else null end as genre_Howard, categories.channel_name channelName 
> from dfs.root.`/SXM/archive/parsed/Channel-parsed-type2/2017-12-14*` channels 
> join dfs.root.`/SXM/archive/parsed/category-parsed-type2/2017-12-14*` 
> categories on categories.channel_guid=channels.channelguid left join (select 
> channel_guid from 
> dfs.root.`/SXM/archive/parsed/category-parsed-type2/2017-12-14*` where 
> supercategory_name = 'Music') music on channels.channelguid = 
> music.channel_guid left join (select channel_guid from 
> dfs.root.`/SXM/archive/parsed/category-parsed-type2/2017-12-14*` where 
> supercategory_name = 'News') news on channels.channelguid = news.channel_guid 
> left join (select channel_guid from 
> dfs.root.`/SXM/archive/parsed/category-parsed-type2/2017-12-14*` where 
> supercategory_name = 'Sports') sports on channels.channelguid = 
> sports.channel_guid left join (select channel_guid from 
> dfs.root.`/SXM/archive/parsed/category-parsed-type2/2017-12-14*` where 
> supercategory_name = 'Talk') talk on channels.channelguid = talk.channel_guid 
> left join (select channel_guid from 
> dfs.root.`/SXM/archive/parsed/category-parsed-type2/2017-12-14*` where 
> supercategory_name = 'Howard') howard on channels.channelguid = 
> howard.channel_guid_|
> |_Auto_AOD_Content:304 - There was a SQL ERROR on DRILL side_|
> |_Auto_AOD_Content:305 - VALIDATION ERROR: A table or view with given name 
> [attributes] already exists in schema [dfs.tmp]_|
>  



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (DRILL-6057) batch kill running queries from web UI

[Kunal Khatua (JIRA)]

[ 
https://issues.apache.org/jira/browse/DRILL-6057?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16351978#comment-16351978
 ] 

Kunal Khatua commented on DRILL-6057:
-

[~weijie] , DRILL-5716 has the ability to control the number of concurrently 
running queries by enqueueing the excess load for a smoother stable operation 
of the Drill cluster. Did you try that?

> batch kill running queries from web UI
> --
>
> Key: DRILL-6057
> URL: https://issues.apache.org/jira/browse/DRILL-6057
> Project: Apache Drill
>  Issue Type: Improvement
>  Components: Tools, Build  Test
>Affects Versions: 1.13.0
> Environment: 
>Reporter: weijie.tong
>Assignee: weijie.tong
>Priority: Minor
>
> Some scenarios, Drill suffers  high concurrency queries and leads to 
> overload. As an administrator, you might  want to quickly batch kill all the 
> running queries to avoid the system from overload and let the system recover 
> from being overloaded.Though we provide a web tool to  kill a running query 
> one by one ,it's not so efficient to this case . 
> So here will provide a web button to kill all the running queries to an 
> administrator.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (DRILL-6057) batch kill running queries from web UI

[Kunal Khatua (JIRA)]

[ 
https://issues.apache.org/jira/browse/DRILL-6057?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16351980#comment-16351980
 ] 

Kunal Khatua commented on DRILL-6057:
-

A solution would be to set the {{exec.queue.large}} to a value that is close 
the max stability you've observed in your cluster. 

> batch kill running queries from web UI
> --
>
> Key: DRILL-6057
> URL: https://issues.apache.org/jira/browse/DRILL-6057
> Project: Apache Drill
>  Issue Type: Improvement
>  Components: Tools, Build  Test
>Affects Versions: 1.13.0
> Environment: 
>Reporter: weijie.tong
>Assignee: weijie.tong
>Priority: Minor
>
> Some scenarios, Drill suffers  high concurrency queries and leads to 
> overload. As an administrator, you might  want to quickly batch kill all the 
> running queries to avoid the system from overload and let the system recover 
> from being overloaded.Though we provide a web tool to  kill a running query 
> one by one ,it's not so efficient to this case . 
> So here will provide a web button to kill all the running queries to an 
> administrator.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (DRILL-6058) Define per connection level OptionManager

[Kunal Khatua (JIRA)]

[ 
https://issues.apache.org/jira/browse/DRILL-6058?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16351982#comment-16351982
 ] 

Kunal Khatua commented on DRILL-6058:
-

[~weijie] Could you provide more details (like examples)? 

> Define per connection level OptionManager
> -
>
> Key: DRILL-6058
> URL: https://issues.apache.org/jira/browse/DRILL-6058
> Project: Apache Drill
>  Issue Type: Improvement
>Reporter: weijie.tong
>Assignee: weijie.tong
>Priority: Minor
> Fix For: 1.13.0
>
>
> We want to control some queries's running frequency which need to be 
> identified by some options .
> One requirement case is we want to control the download query times, but 
> allow the normal queries to run. So we need to define a connection level 
> OptionManager .



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (DRILL-6059) Apply needed StoragePlugins's RuleSet to the planner

[Kunal Khatua (JIRA)]

[ 
https://issues.apache.org/jira/browse/DRILL-6059?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16351983#comment-16351983
 ] 

Kunal Khatua commented on DRILL-6059:
-

This is most likely addressed by DRILL-5089.

> Apply needed StoragePlugins's RuleSet to the planner
> 
>
> Key: DRILL-6059
> URL: https://issues.apache.org/jira/browse/DRILL-6059
> Project: Apache Drill
>  Issue Type: Improvement
>Reporter: weijie.tong
>Assignee: weijie.tong
>Priority: Minor
> Fix For: 1.13.0
>
>
> Now once we configure Drill with more than one StoragePlugins, it will apply 
> all the plugins's rules to user's queries even the queries not contain 
> corresponding storage plugin. The reason is the method below of QueryContext
> {code:java}
>   public StoragePluginRegistry getStorage() {
> return drillbitContext.getStorage();
>   }
> {code}
>  
> From QueryContext's name , the method  should return the query involved 
> storage plugin registry not all the configured storage plugins. 
> So we need to identify the involved storage plugin at the parse stage, and 
> set the collected involved storage plugins to the QueryContext. This will 
> also benefit the work to do a schema level security control. Maybe a new 
> method with the name getInvolvedStorage will be more accurate.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (DRILL-6012) Query Oracle RMAN without restoring a DB

[Kunal Khatua (JIRA)]

[ 
https://issues.apache.org/jira/browse/DRILL-6012?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16352092#comment-16352092
 ] 

Kunal Khatua commented on DRILL-6012:
-

It might be a good idea to share this in the Dev mailing list and see what 
developers in the  community have to say.

> Query Oracle RMAN without restoring a DB
> 
>
> Key: DRILL-6012
> URL: https://issues.apache.org/jira/browse/DRILL-6012
> Project: Apache Drill
>  Issue Type: New Feature
>  Components: Storage - Other
>Reporter: Daniel Petisme
>Priority: Minor
>
> Oracle backups are stored under a RMAN (Recovery Manager) format.
> https://docs.oracle.com/cd/E11882_01/backup.112/e10642/rcmquick.htm
> With the raise of BigData, we want to query all possible data. Nevertheless, 
> is sometimes hard to get access to actual living data where backups are often 
> easy to get but hard to restore properly.
> The aim of this feature would be to query the RMAN file without actually 
> restoring the database. I don't know if it's even feasible but would be a 
> great help to ease the data access. 
> As far as I know, RMAN are binary formats (I guess propriatary) which 
> contains some structure meta-data (indices, for instance) and the actual data.
> IMHO, in that context performance is not a first-class constraint is more an 
> exploration tool I have in mind.
> Does make sense? What's you thoughts on this idea ?



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Updated] (DRILL-5993) Improve Performance of Copiers used by SV Remover, Top N etc.

[Kunal Khatua (JIRA)]

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

Kunal Khatua updated DRILL-5993:

Labels:   (was: ready-to-commit)

> Improve Performance of Copiers used by SV Remover, Top N etc.
> -
>
> Key: DRILL-5993
> URL: https://issues.apache.org/jira/browse/DRILL-5993
> Project: Apache Drill
>  Issue Type: Improvement
>Reporter: Timothy Farkas
>Assignee: Timothy Farkas
>Priority: Major
> Fix For: 1.13.0
>
>
> Currently the copier can only copy record from an incoming batch to the 
> beginning of an outgoing batch. We need to be able to copy a record and 
> append it to the end of the outgoing batch. Also Paul's Generic copiers are 
> more performant and simpler and should be added.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Updated] (DRILL-5993) Improve Performance of Copiers used by SV Remover, Top N etc.

[Kunal Khatua (JIRA)]

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

Kunal Khatua updated DRILL-5993:

Labels: ready-to-commit  (was: )

> Improve Performance of Copiers used by SV Remover, Top N etc.
> -
>
> Key: DRILL-5993
> URL: https://issues.apache.org/jira/browse/DRILL-5993
> Project: Apache Drill
>  Issue Type: Improvement
>Reporter: Timothy Farkas
>Assignee: Timothy Farkas
>Priority: Major
>  Labels: ready-to-commit
> Fix For: 1.13.0
>
>
> Currently the copier can only copy record from an incoming batch to the 
> beginning of an outgoing batch. We need to be able to copy a record and 
> append it to the end of the outgoing batch. Also Paul's Generic copiers are 
> more performant and simpler and should be added.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)