[
https://issues.apache.org/jira/browse/PHOENIX-7006?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17823814#comment-17823814
]
ASF GitHub Bot commented on PHOENIX-7006:
-----------------------------------------
virajjasani commented on code in PR #1751:
URL: https://github.com/apache/phoenix/pull/1751#discussion_r1513665591
##########
phoenix-core-server/src/main/java/org/apache/phoenix/coprocessor/BaseScannerRegionObserver.java:
##########
@@ -527,6 +535,28 @@ public static boolean isMaxLookbackTimeEnabled(long
maxLookbackTime){
return maxLookbackTime > 0L;
}
+ public static long
getMaxLookbackAge(ObserverContext<RegionCoprocessorEnvironment> c) {
+ TableName tableName =
c.getEnvironment().getRegion().getRegionInfo().getTable();
+ String fullTableName = tableName.getNameAsString();
+ Configuration conf = c.getEnvironment().getConfiguration();
+ PTable table;
+ try(PhoenixConnection conn = QueryUtil.getConnectionOnServer(
+ conf).unwrap(PhoenixConnection.class)) {
+ table = conn.getTableNoCache(fullTableName);
+ }
+ catch (Exception e) {
+ if (e instanceof TableNotFoundException) {
+ LOGGER.debug("Ignoring HBase table that is not a Phoenix
table: "
+ + fullTableName);
Review Comment:
It's perf improvement depending on the size of the string. When heavy
objects are to be logged and if we use non-param version, the string
concatenation happens even though the given logger level is not enabled (e.g.
even if log level is INFO and the above DEBUG log is not going to be printed,
the string concatenation still happens), whereas if we use parameterized
version, the string concatenation happens only if the given logger level is
enabled and the log is expected to be printed. With parameterized version, the
string concatenation takes place within log4j implementation.
> Configure maxLookbackAge at table level
> ---------------------------------------
>
> Key: PHOENIX-7006
> URL: https://issues.apache.org/jira/browse/PHOENIX-7006
> Project: Phoenix
> Issue Type: Improvement
> Reporter: Viraj Jasani
> Assignee: Sanjeet Malhotra
> Priority: Major
>
> Phoenix max lookback age feature preserves live or deleted row versions that
> are only visible through the max lookback window, it does not preserve any
> unwanted row versions that should not be visible through the max lookback
> window. More details on the max lookback redesign: PHOENIX-6888
> As of today, maxlookback age is only configurable at the cluster level
> (config key: {_}phoenix.max.lookback.age.seconds{_}), meaning the same value
> is used by all tables. This does not allow individual table level compaction
> scanner to be able to retain data based on the table level maxlookback age.
> Setting max lookback age at the table level can serve multiple purposes e.g.
> change-data-capture (PHOENIX-7001) for individual table should have it's own
> latest data retention period.
> The purpose of this Jira is to allow maxlookback age as a table level
> property:
> * New column in SYSTEM.CATALOG to preserve table level maxlookback age
> * PTable object to read the value of maxlookback from SYSTEM.CATALOG
> * Allow CREATE/ALTER TABLE DDLs to provide maxlookback attribute
> * CompactionScanner should use table level maxlookbackAge, if available,
> else use cluster level config
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
