Also I meant to quickly clarify: This isn't specific to 15452 and I
think discussion of 15452 should happen on a separate thread, if at all. I
personally haven't come to an opinion myself and hadn't planned to broach
that subject yet. It was one example of where this discussion had come up
between
Thanks for the initial feedback. I hear a couple different themes / POVs.
David/Paulo, it sounds like maybe a guide for perf backports + mailing list
consensus when necessary + clear documentation of this could be a way
forward. I agree that each change comes with stability risks but at the
same t
I think this is an idea worth exploring, my guess is that even if the scope
is confined to just "copy if not exists" it would still largely be used as
a cloud-agnostic backup/restore solution, and so will be shaped accordingly.
Some thoughts:
- I think it would be worth exploring more what the di
We expect users to treat patch and minor releases as low risk. Changing
something deep in the storage engine to be 1% faster is not worth the risk,
because most users will skip the type of qualification that finds those one in
a billion regressions.
Patch releases are for bug fixes not perf imp
Hi Danny,
Thanks for pinging this ist. It would be helpful for you to indicate on
that JIRA that you're picking up the issue. Right now the JIRA is not
assigned to anybody. I don't think you have a JIRA account. Could you
please request[1] one? Once you have it, I will assign you the ticket and
yo
Thanks for starting this discussion Jordan. Even though I'm not familiar
with the specific changes proposed by CASSANDRA-15452, see my comments on
generally allowing performance improvements to old branches.
> I believe they should target every active branch because performance is a
major selling
I think Paulo and I are in-sync on this. For me 4.x is mostly about stability
right now and 5.x is more active development; so I have a higher bar for back
ports to 4.x than I do to 5.x. There is also the question on “risk” which can
be subjective from reviewer to reviewer. Some patches may be
Hi folks,
A topic that’s come up recently is what branches are valid targets for
performance improvements. Should they only go into trunk? This has come up
in the context of BTI improvements, Dmitry’s work on reducing object
overhead, and my work on CASSANDRA-15452.
We currently have guidelines p
If you ask specifically about how TTL snapshots are handled, there is a
thread running with a task scheduled every n seconds (not sure what is the
default) and it just checks against "expired_at" field in manifest if it is
expired or not. If it is then it will proceed to delete it as any other
snap
On Tue, Jan 21, 2025 at 5:30 AM Francisco Guerrero
wrote:
> I think we should evaluate the benefits of the feature you are proposing
> independently on how it might be used by Sidecar or other tools. As it
> is, it already sounds like a useful functionality to have in the core of
> the
> Cassandr
10 matches
Mail list logo
