pcmanus commented on code in PR #3688:
URL: https://github.com/apache/cassandra/pull/3688#discussion_r1873465002
##########
src/java/org/apache/cassandra/db/repair/CassandraValidationIterator.java:
##########
@@ -221,7 +222,7 @@ public CassandraValidationIterator(ColumnFamilyStore cfs,
SharedContext ctx, Col
long gcBefore = dontPurgeTombstones ? Long.MIN_VALUE :
getDefaultGcBefore(cfs, nowInSec);
controller = new ValidationCompactionController(cfs, gcBefore);
- scanners = cfs.getCompactionStrategyManager().getScanners(sstables,
ranges);
+ scanners = ScannerFactory.DEFAULT.getScanners(sstables, ranges);
Review Comment:
In principle, I love simplifying code and would rather we get rid of the
special case, especially since LCS is in my mind kind of deprecated (in favor
of UCS). But I'm sure plenty of users still use LCS and the truth is that I
have no good intuition on the impact of this. What's the concrete impact of
removing that LCS scanner for compaction? and for validation/anti-compaction? I
feel the right decision mostly depend on the answer to those questions (unless
we've officially deprecated LCS, but I don't think that's the case)?
I do understand doing benchmark might be time consuming though. I just feel
I'm lacking proper data to have an opinion at the moment. But my only concern
is making sure LCS users don't experience a clearly noticeable performance
because of this; I'm not attached at all to that special scanner otherwise.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
