[ 
https://issues.apache.org/jira/browse/PHOENIX-5131?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16788453#comment-16788453
 ] 

Abhishek Singh Chouhan commented on PHOENIX-5131:
-------------------------------------------------

Thanks for having a look [~vincentpoon], have made changes based on your 
suggestions. 

> Also, can we cache these properties in a field at factory creation, or are 
>you expecting them to be dynamically changed?

The spool parameters can be set by the client and can be different for 
different queries. Also the factory is used on both the server and client and 
spooling values on server and client can be different. I thought it would be 
best to  leave it stateless and have the caller supply the args.

 

Based on discussion with [~tdsilva] have also added logic to handle decoding 
the thresholdBytes from scan based on the version of client(separate for 5.x 
and 4.x) and test for that. 

> Make spilling to disk for order/group by configurable
> -----------------------------------------------------
>
>                 Key: PHOENIX-5131
>                 URL: https://issues.apache.org/jira/browse/PHOENIX-5131
>             Project: Phoenix
>          Issue Type: Improvement
>            Reporter: Abhishek Singh Chouhan
>            Assignee: Abhishek Singh Chouhan
>            Priority: Major
>             Fix For: 4.15.0, 5.1.0
>
>         Attachments: PHOENIX-5131-master-v2.patch, 
> PHOENIX-5131-master-v2.patch, PHOENIX-5131-master-v3.patch, 
> PHOENIX-5131-master.patch, PHOENIX-5131-master.patch
>
>
> We've observed that large queries, doing order/group by leading to issues on 
> the regionserver (crashes/long gc pauses/file handler exhaustion etc.). We 
> should make spilling to disk configurable and in case its disabled, fail the 
> query once it hits the spilling limit on any of the region servers. Also make 
> spooling threshold server-side property only to prevent clients from 
> controlling memory allocation on the rs side.



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

Reply via email to