[jira] [Updated] (CASSANDRA-4416) Include metadata for system keyspace itself in schema_* tables
[
https://issues.apache.org/jira/browse/CASSANDRA-4416?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jonathan Ellis updated CASSANDRA-4416:
--
Attachment: 4416.txt
Patch attached implementing Sylvain's suggestion to delete out and write anew
the schema entries for hardcoded tables.
Also removes SSTableExport restriction that you can only run it if non-system
tables have been defined which is kind of nonsensical.
Include metadata for system keyspace itself in schema_* tables
--
Key: CASSANDRA-4416
URL: https://issues.apache.org/jira/browse/CASSANDRA-4416
Project: Cassandra
Issue Type: Improvement
Components: Core
Affects Versions: 1.2.0 beta 1
Reporter: paul cannon
Priority: Minor
Labels: cql, cql3
Fix For: 1.2.0 beta 2
Attachments: 4416.txt
The `system.schema_keyspaces`, `system.schema_columnfamilies`, and
`system.schema_columns` virtual tables allow clients to query schema and
layout information through CQL. This will be invaluable when users start to
make more use of the CQL-only protocol (CASSANDRA-2478), since there will be
no other way to determine certain information about available columnfamilies,
keyspaces, or show metadata about them.
However, the system keyspace itself, and all the columnfamilies in it, are
not represented in the schema_* tables:
{noformat}
cqlsh select * from system.schema_keyspaces where keyspace = 'system';
cqlsh
cqlsh select * from system.schema_columnfamilies where keyspace = 'system';
cqlsh
cqlsh select * from system.schema_columns where keyspace = 'system';
cqlsh
{noformat}
It would be greatly helpful to clients which do more introspection than the
minimum (say, for example, cqlsh) to be able to get information on the
structure and availability of schema-definition tables.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CASSANDRA-4705) Speculative execution for CL_ONE
[ https://issues.apache.org/jira/browse/CASSANDRA-4705?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13466390#comment-13466390 ] Vijay commented on CASSANDRA-4705: -- I pushed the prototype code into https://github.com/Vijay2win/cassandra/commit/62bbabfc41ba8e664eb63ba50110e5f5909b2a87 Looks like metrics-core exposes 75, 95, 97, 99 and 99.9 Percentile's, with my tests 75P is too low, and 99 is too high to make a difference, whereas 95P long tail looks better (Moving average doesn't make much of a difference too). I still think we should also support hard coded value in addition to the auto :) Note: have to make the speculative_retry part of the schema but currently if you want to test it out it is a code change in CFMetaData Speculative execution for CL_ONE Key: CASSANDRA-4705 URL: https://issues.apache.org/jira/browse/CASSANDRA-4705 Project: Cassandra Issue Type: Improvement Affects Versions: 1.2.0 Reporter: Vijay Assignee: Vijay Priority: Minor When read_repair is not 1.0, we send the request to one node for some of the requests. When a node goes down or when a node is too busy the client has to wait for the timeout before it can retry. It would be nice to watch for latency and execute an additional request to a different node, if the response is not received within average/99% of the response times recorded in the past. CASSANDRA-2540 might be able to solve the variance when read_repair is set to 1.0 1) May be we need to use metrics-core to record various Percentiles 2) Modify ReadCallback.get to execute additional request speculatively. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Comment Edited] (CASSANDRA-4705) Speculative execution for CL_ONE
[ https://issues.apache.org/jira/browse/CASSANDRA-4705?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13466390#comment-13466390 ] Vijay edited comment on CASSANDRA-4705 at 9/30/12 2:02 PM: --- I pushed the prototype code into https://github.com/Vijay2win/cassandra/commit/62bbabfc41ba8e664eb63ba50110e5f5909b2a87 Looks like metrics-core exposes 75, 95, 97, 99 and 99.9 Percentile's, with my tests 75P is too low, and 99 is too high to make a difference, whereas 95P long tail looks better (Moving average doesn't make much of a difference too). It also supports ALL, AUTO, NONE (current behavior) as per jonathan's comment above. But I still think we should also support hard coded value in addition to the auto :) Note: have to make the speculative_retry part of the schema but currently if you want to test it out it is a code change in CFMetaData was (Author: vijay2...@yahoo.com): I pushed the prototype code into https://github.com/Vijay2win/cassandra/commit/62bbabfc41ba8e664eb63ba50110e5f5909b2a87 Looks like metrics-core exposes 75, 95, 97, 99 and 99.9 Percentile's, with my tests 75P is too low, and 99 is too high to make a difference, whereas 95P long tail looks better (Moving average doesn't make much of a difference too). I still think we should also support hard coded value in addition to the auto :) Note: have to make the speculative_retry part of the schema but currently if you want to test it out it is a code change in CFMetaData Speculative execution for CL_ONE Key: CASSANDRA-4705 URL: https://issues.apache.org/jira/browse/CASSANDRA-4705 Project: Cassandra Issue Type: Improvement Affects Versions: 1.2.0 Reporter: Vijay Assignee: Vijay Priority: Minor When read_repair is not 1.0, we send the request to one node for some of the requests. When a node goes down or when a node is too busy the client has to wait for the timeout before it can retry. It would be nice to watch for latency and execute an additional request to a different node, if the response is not received within average/99% of the response times recorded in the past. CASSANDRA-2540 might be able to solve the variance when read_repair is set to 1.0 1) May be we need to use metrics-core to record various Percentiles 2) Modify ReadCallback.get to execute additional request speculatively. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
