[
https://issues.apache.org/jira/browse/PHOENIX-180?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14102580#comment-14102580
]
ramkrishna.s.vasudevan commented on PHOENIX-180:
------------------------------------------------
Updates on the JIRA
-> Provides a SQL stmt to collect the statistics.
-> Uses a chore to update the statistics in the MetaDataEndpointImpl. In the
previous patch had done this differently by using a callable where based on the
frequency of updation the new stats or older stats would be returned. Now it
will be done by the Chore.
-> The change in stats will invalidate the table in GlobalCache.
-> One thing to note is that for invalidating the cache we need the tenantid,
schema name and the table name. So now trying to set it in the Request passed
to the endpoint. But the challenge is while doing preCompactScanner() we need
to get these tenantId and schemaName. So should we do this
{code}
conn =
DriverManager.getConnection(getJdbcUrl()).unwrap(PhoenixConnection.class);
{code}
as done in MetaDataRegionObserver?
> Use stats to guide query parallelization
> ----------------------------------------
>
> Key: PHOENIX-180
> URL: https://issues.apache.org/jira/browse/PHOENIX-180
> Project: Phoenix
> Issue Type: Sub-task
> Reporter: James Taylor
> Assignee: ramkrishna.s.vasudevan
> Labels: enhancement
> Attachments: Phoenix-180_WIP.patch
>
>
> We're currently not using stats, beyond a table-wide min key/max key cached
> per client connection, to guide parallelization. If a query targets just a
> few regions, we don't know how to evenly divide the work among threads,
> because we don't know the data distribution. This other [issue]
> (https://github.com/forcedotcom/phoenix/issues/64) is targeting gather and
> maintaining the stats, while this issue is focused on using the stats.
> The main changes are:
> 1. Create a PTableStats interface that encapsulates the stats information
> (and implements the Writable interface so that it can be serialized back from
> the server).
> 2. Add a stats member variable off of PTable to hold this.
> 3. From MetaDataEndPointImpl, lookup the stats row for the table in the stats
> table. If the stats have changed, return a new PTable with the updated stats
> information. We may want to cache the stats row and have the stats gatherer
> invalidate the cache row when updated so we don't have to always do a scan
> for it. Additionally, it would be idea if we could use the same split policy
> on the stats table that we use on the system table to guarantee co-location
> of data (for the sake of caching).
> - modify the client-side parallelization (ParallelIterators.getSplits()) to
> use this information to guide how to chunk up the scans at query time.
> This should help boost query performance, especially in cases where the data
> is highly skewed. It's likely the cause for the slowness reported in this
> issue: https://github.com/forcedotcom/phoenix/issues/47.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
