[
https://issues.apache.org/jira/browse/CASSANDRA-20899?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=18019657#comment-18019657
]
Stefan Miklosovic commented on CASSANDRA-20899:
-----------------------------------------------
Great patch. I think it is worth to take a look at LogMessagesTable which can
hold system logs. It is currently
{code}
super(TableMetadata.builder(keyspace, TABLE_NAME)
.comment(TABLE_COMMENT)
.kind(TableMetadata.Kind.VIRTUAL)
.partitioner(new
LocalPartitioner(TimestampType.instance))
.addPartitionKeyColumn(TIMESTAMP_COLUMN_NAME,
TimestampType.instance)
.addClusteringColumn(ORDER_IN_MILLISECOND_COLUMN_NAME, Int32Type.instance)
.addRegularColumn(LOGGER_COLUMN_NAME,
UTF8Type.instance)
.addRegularColumn(LEVEL_COLUMN_NAME,
UTF8Type.instance)
.addRegularColumn(MESSAGE_COLUMN_NAME,
UTF8Type.instance).build(),
size);
{code}
when when somebody does
select message from system_views.system_logs, for now it discards everything
but messages column. That table can handle 100k rows max. If we take into
consideration LOGGER_COLUMN_NAME which holds name of a logger. not a lot of
times we need to see the logger itself, we just want to see time and message.
But for now we would still go through the logic populating that column while it
is completely unnecessary.
> Lazy Virtual Tables
> -------------------
>
> Key: CASSANDRA-20899
> URL: https://issues.apache.org/jira/browse/CASSANDRA-20899
> Project: Apache Cassandra
> Issue Type: Improvement
> Components: Virtual Tables
> Reporter: Benedict Elliott Smith
> Priority: Normal
>
> Virtual tables construct their result eagerly by default, with no protection
> against time or heap overruns, which has proven to be a problem for some
> Accord debug virtual tables.
> This patch introduces AbstractLazyVirtualTable that is just as easy to use
> (requires minimal porting), but:
> - aborts the query if it is taking too long
> - eagerly filters rows by any search criteria, and discards any columns we
> are not selecting
> - eagerly applies limits to the records it collects, so that we never keep
> more than some multiple of the final result set in memory
> - supports lazy materialisation of rows (at caller's discretion), so we can
> avoid formatting inputs until they have been excluded by the above filters
> - can exploit in-order visitation to tightly bound this extra work
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
