[
https://issues.apache.org/jira/browse/PHOENIX-2724?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15352402#comment-15352402
]
James Taylor commented on PHOENIX-2724:
---------------------------------------
[~samarthjain], [~mujtabachohan] - I think the reason is the sizing of the
client-side cache:
{code}
+ public static final long DEFAULT_STATS_MAX_CACHE_SIZE = 256 * 1024 * 1024;
{code}
Previously, the server-side cache was being used (which I think is bigger). If
the cache is too small, we end up making an RPC each time to get the stats.
[~mujtabachohan] - as a first test, can you try increasing that cache size
{{phoenix.stats.cache.maxSize}}? This will be an important config parameter. We
might want to switch it to being a percentage of the heap instead of an
absolute time.
Another pretty easy fix would be to not try to get the guideposts for certain
queries - point lookups and serial queries. We're fine just using the region
boundaries in those cases.
[~lhofhansl] - I think the cost here is likely pulling over all the guideposts
with each query. I like your idea, but we'd probably want to do that on the
server-side and I think it's too big a change for 4.8. There's some other
things we can do too, like making stats configurable on a per table basis,
potentially only pulling over some of the stats (based on start/stop key), not
caching guideposts beyond a threshold (so we don't churn the cache), etc. Needs
a bit of design, thought. IMHO, with the above, we'll be good enough to go for
4.8.
> Query with large number of guideposts is slower compared to no stats
> --------------------------------------------------------------------
>
> Key: PHOENIX-2724
> URL: https://issues.apache.org/jira/browse/PHOENIX-2724
> Project: Phoenix
> Issue Type: Bug
> Affects Versions: 4.7.0
> Environment: Phoenix 4.7.0-RC4, HBase-0.98.17 on a 8 node cluster
> Reporter: Mujtaba Chohan
> Assignee: Samarth Jain
> Fix For: 4.8.0
>
> Attachments: PHOENIX-2724.patch, PHOENIX-2724_addendum.patch,
> PHOENIX-2724_v2.patch
>
>
> With 1MB guidepost width for ~900GB/500M rows table. Queries with short scan
> range gets significantly slower.
> Without stats:
> {code}
> select * from T limit 10; // query execution time <100 msec
> {code}
> With stats:
> {code}
> select * from T limit 10; // query execution time >20 seconds
> Explain plan: CLIENT 876085-CHUNK 476569382 ROWS 876060986727 BYTES SERIAL
> 1-WAY FULL SCAN OVER T SERVER 10 ROW LIMIT CLIENT 10 ROW LIMIT
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
