[
https://issues.apache.org/jira/browse/PHOENIX-2706?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
James Taylor reopened PHOENIX-2706:
-----------------------------------
Not crazy about the current solutions, as the client knowing that stats are
disabled does not definitely determine that a table without guideposts is a
table that is smaller than the guidepost width. Stats may have been disabled
after the guideposts were generated, for example. Also, it says nothing about
other tables, even if a given table has stats.
My current thinking is to revert this change and do the following instead:
- in DefaultStatisticsCollector.writeStatsToStatsTable(), if there are no stats
to write, write a row with the physicalTable+columnFamily for the row key and a
byteCount and rowCount of zero (in addition to what's being done now).
- otherwise, always write a Delete for the physicalTable+columnFamily row. In
this way, only if all regions of a given column family have no guideposts, will
this row remain.
- in StatisticsWriter.deleteStats(), always write a Delete marker for the
physicalTable+columnFamily row.
- ensure that an empty PGuidePosts can be differentiated from no PGuidePosts.
Perhaps something like a encodedGuidePostsCount of 0 for an empty one and -1
for a non existent one.
- in GuidePostsInfo constructor, if guidePostsCount is -1, set a new
wasCalculated member variable to false and add a wasCalculated() method
accessor for it.
- in BaseResultIterators.getParallelScans(), set the areStatsEnabled to true or
false based on GuidePostsInfo.wasCalculated().
> Implement client-side mechanism to know if stats are enabled
> ------------------------------------------------------------
>
> Key: PHOENIX-2706
> URL: https://issues.apache.org/jira/browse/PHOENIX-2706
> Project: Phoenix
> Issue Type: Bug
> Reporter: James Taylor
> Assignee: James Taylor
> Fix For: 4.7.0
>
> Attachments: PHOENIX-2706.patch, PHOENIX-2706_final.patch
>
>
> Since Phoenix does query planning and explain plan generation on the
> client-side, we need a way to distinguish between a table being too small to
> have stats and stats being disabled. This new API will provide that on
> ConnectionQueryServices and be updated in the following places:
> - during initial cluster connection (ConnectionQueryServices.init()).
> - during UPDATE STATISTICS (based on return value)
> - when guideposts are traversed in BaseResultIterators.getParallelScans().
> The value would only traverse from false to true in this case if we get back
> guideposts on the PTable.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
