[
https://issues.apache.org/jira/browse/PHOENIX-5634?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17001990#comment-17001990
]
Lars Hofhansl commented on PHOENIX-5634:
----------------------------------------
Choosing the cache frequency - technically it's an interval, since we provide a
time unit, not cycles per time unit, but anyway - per connection is powerful.
One could set a permissive default and then control for connections that really
need it exact (or vice versa).
Also ...
There are other models. Can we be smarter about this and know when a table is
out of date without checking each time? Or can we start the query and then
during the query detect an out of date table and then restart? Or something
else? [~gjacoby] had some ideas.
In any case this is a good start.
> Use 'phoenix.default.update.cache.frequency' from connection properties at
> query time
> -------------------------------------------------------------------------------------
>
> Key: PHOENIX-5634
> URL: https://issues.apache.org/jira/browse/PHOENIX-5634
> Project: Phoenix
> Issue Type: Improvement
> Affects Versions: 4.15.0
> Reporter: Nitesh Maheshwari
> Assignee: Nitesh Maheshwari
> Priority: Minor
> Fix For: 4.15.1
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> We have the config 'phoenix.default.update.cache.frequency' which specifies
> the time a client should wait before it refreshes its metadata cache entry
> for a table by fetching the latest metadata from system catalog. This value
> could be set for a table in the following ways (in the following preference
> order):
> # Specifying UPDATE_CACHE_FREQUENCY in table creation DDL
> # Specifying the connection property 'phoenix.default.update.cache.frequency'
> # Using the default 'phoenix.default.update.cache.frequency'
> At query time, we look at whether UPDATE_CACHE_FREQUENCY was specified for
> the table and decide based on that value if the latest metadata for a table
> should be fetched from system catalog to update the cache. However, when the
> table doesn't have UPDATE_CACHE_FREQUENCY specified we should look at the
> connection property 'phoenix.default.update.cache.frequency' (or the default
> 'phoenix.default.update.cache.frequency' when the connection level property
> is not set) to make that decision. The support for latter is missing - this
> Jira is intended to add that.
> This will aid exiting installations where the tables were created without a
> specified UPDATE_CACHE_FREQUENCY, and thus always hit the system catalog to
> get the latest metadata when referenced. With this support, we will be able
> to reduce the load on system catalog by specifying a connection level
> property for all tables referenced from the connection (as against UPSERTing
> each table entry in system catalog to set an UPDATE_CACHE_FREQUENCY value).
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
