[
https://issues.apache.org/jira/browse/PHOENIX-2724?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15360423#comment-15360423
]
James Taylor commented on PHOENIX-2724:
---------------------------------------
+1. Wow, what a difference - nice work, [~lhofhansl]! The reason we had
KEEP_DELETED_CELL=true for SYSTEM.STATS was to match SYSTEM.CATALOG. In theory,
someone could connect at an earlier timestamp and run UPDATE STATS which would
generate stats for that point in time. However, a major compaction would always
derive stats for the latest data, so it's not a complete picture (plus I doubt
anyone uses stats this way) and it's clearly not worth it given the time
difference in time you've shown.
You've probably seen, but the initial setting of KEEP_DELETED_CELLS for a new
Phoenix installation is in QueryConstants.java. I suppose we should update the
HTableDescriptor in the catch TableAlreadyExistsException when we create the
table in ConnectionQueryServicesImpl.init(). Should we force a major compaction
too?
Given those differences in timing, should we consider setting
KEEP_DELETED_CELLS to false for SYSTEM.CATALOG as well?
> 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: 2724.txt, 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)
