phoenix-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Thomas D'Silva (JIRA)" <>
Subject [jira] [Commented] (PHOENIX-4023) Handle drop of shared index when UPDATE_CACHE_FREQUENCY is set
Date Fri, 14 Jul 2017 18:47:00 GMT


Thomas D'Silva commented on PHOENIX-4023:

Option #2 seems like the best one. If we a dropping a parent table/view index we have to wait
for the max of UPDATE_CACHE_FREQUENCY of the all child views that are able to use the index?

> Handle drop of shared index when UPDATE_CACHE_FREQUENCY is set
> --------------------------------------------------------------
>                 Key: PHOENIX-4023
>                 URL:
>             Project: Phoenix
>          Issue Type: Bug
>            Reporter: James Taylor
> When UPDATE_CACHE_FREQUENCY is set, a client will continue to use a shared index (i.e.
local index or view index). This is not good because once it's dropped, it will stop being
maintained which will lead to incorrect query results.
> Some potential options:
> # Ignore UPDATE_CACHE_FREQUENCY if a table has a shared index. Not great because it defeats
the purpose of the feature.
> # Delay the index actually being dropped (or at least the stopping of the maintenance)
until the cache frequency passes. Makes some assumptions about the UPDATE_CACHE_FREQUENCY
as it could vary on a connection by connection basis.
> #. Do nothing and let the index continue to be used (figuring it's usage will stop when
the UPDATE_CACHE_FREQUENCY occurs and that's the cost of using this feature).
> Option #2 seems the most viable. Perhaps a separate config for how long to continue to
do index maintenance after an index is dropped.

This message was sent by Atlassian JIRA

View raw message