[
https://issues.apache.org/jira/browse/PHOENIX-3040?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15360428#comment-15360428
]
James Taylor commented on PHOENIX-3040:
---------------------------------------
Since there's a cost to getting the stats (potentially an RPC, caching the
stats which may end up evicting cached stats for other tables, and more key
comparisons), my thinking is that this change is an improvement regardless of
PHOENIX-2724. If we had a way of turning stats off per table (PHOENIX-2675),
then this might be less necessary, but we don't have that yet.
Looking closer at the patch, though, I think it can be simplified. I don't
understand the necessity of having both
NONFILTERED_AND_LIMITED_QUERY_SERIAL_THRESHOLD and
FILTERED_OR_NONLIMITED_QUERY_SERIAL_THRESHOLD. I'd fold those into one, keeping
the NONFILTERED_AND_LIMITED_QUERY_SERIAL_THRESHOLD and renaming it to
LIMITED_QUERY_SERIAL_THRESHOLD. If the query has a filter, we can compute the
bytes threshold from this config parameter instead of hard coding the limit as
being 2 guideposts. It'd be more consistent IMHO.
[~samarthjain].
> Don't use guideposts for executing queries serially
> ---------------------------------------------------
>
> Key: PHOENIX-3040
> URL: https://issues.apache.org/jira/browse/PHOENIX-3040
> Project: Phoenix
> Issue Type: Bug
> Reporter: Samarth Jain
> Assignee: Samarth Jain
> Fix For: 4.8.0
>
> Attachments: PHOENIX-3040.patch, PHOENIX-3040_v2.patch
>
>
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
