On Sun, Jul 16, 2023 at 11:47 PM Berenguer Blasi
wrote:
> one q that came up during the review: What should we do if we find a
> markForDeleteAt (mfda) usging the MSByte? That is a mfda beyond year 4254:
>
> A. That is a mistake/bug. I makes no sense when localDeletionTime can't
> already go any
Hi All,
one q that came up during the review: What should we do if we find a
markForDeleteAt (mfda) usging the MSByte? That is a mfda beyond year 4254:
A. That is a mistake/bug. I makes no sense when localDeletionTime can't
already go any further than year 2106. We should reject/fail, maybe l
Hi All,
https://issues.apache.org/jira/browse/CASSANDRA-18648 up for review and
the PR is quite small
Regards
On 3/7/23 11:03, Berenguer Blasi wrote:
Thanks for the comments Benedict. Given DeletionTime.localDeletionTime
is what caps everything to year 2106 (uint enconded now) I am ok with
Thanks for the comments Benedict. Given DeletionTime.localDeletionTime
is what caps everything to year 2106 (uint enconded now) I am ok with a
DeletionTime.markForDeleteAt that can go up to year 4284, personal
opinion ofc.
And yes I hope once I read, doc and understand the sstable format bette
I checked and I’m pretty sure we do, but it doesn’t apply any liveness optimisation. I had misunderstood the optimisation you proposed. Ideally we would encode any non-live timestamp with the delta offset, but since that’s a distinct optimisation perhaps that can be left to another patch.Are we hap
It can look into it. I don't have a deep knowledge of the sstable format
hence why I wanted to document it someday. But DeletionTime is being
serialized in other places as well iirc and I doubt (finger in the air)
we'll have that Epoch handy.
On 29/6/23 17:22, Benedict wrote:
So I’m just takin
The idea is 11 bytes less per LIVE partition. So small partitions will
benefit the most.
On 29/6/23 18:44, Brandon Williams wrote:
On Thu, Jun 29, 2023 at 11:42 AM Jeff Jirsa wrote:
3-4% reduction on disk ... for what exactly?
It seems exceptionally uncommon to have 3% of your data SIZE be t
On Thu, Jun 29, 2023 at 11:42 AM Jeff Jirsa wrote:
> 3-4% reduction on disk ... for what exactly?
>
> It seems exceptionally uncommon to have 3% of your data SIZE be tombstones.
If the data is TTL'd I think it's not entirely uncommon.
Kind Regards,
Brandon
On Thu, Jun 22, 2023 at 11:23 PM Berenguer Blasi
wrote:
> Hi all,
>
> Given we're already introducing a new sstable format (OA) in 5.0 I would
> like to try to get this in before the freeze. The point being that
> sstables with lots of small partitions would benefit from a smaller DT
> at partiti
So I’m just taking a quick peek at SerializationHeader and we already have a
method for reading and writing a deletion time with offsets from EncodingStats.
So perhaps we simply have a bug where we are using DeletionTime Serializer
instead of SerializationHeader.writeLocalDeletionTime? It looks
> I would prefer we not plan on two distinct changes to this
I agree with this sentiment, **and**
> +1, if you have time for this approach and no other in this window.
People are going to use 5.0 for awhile. Better to have an improvement in their
hands for that duration than no improvement at all
>
> Just for completeness the change is a handful loc. The rest is added tests
> and we'd loose the sstable format change opportunity window.
>
+1, if you have time for this approach and no other in this window.
(If you have time for the other, or someone else does, then the technically
superior
Just for completeness the change is a handful loc. The rest is added
tests and we'd loose the sstable format change opportunity window.
Thx again for the replies.
On 26/6/23 9:33, Benedict wrote:
I would prefer we not plan on two distinct changes to this,
particularly when neither change is pa
I would prefer we not plan on two distinct changes to this, particularly when neither change is particularly more complex than the other. There is a modest cost to maintenance from changing this multiple times. But if others feel strongly otherwise I won’t stand in the way.On 26 Jun 2023, at 05:49,
Thanks for the replies.
I intend to javadoc the ssatble format in detail someday and more
improvements might come up then, along the vint encoding mentioned here.
But unless sbdy volunteers to do that in 5.0, is anybody against I try
to get the original proposal (1 byte flags for sentinel valu
> If we’re doing this, why don’t we delta encode a vint from some per-sstable
> minimum value? I’d expect that to commonly compress to a single byte or so.
+1 to this approach.
> Distant future people will not be happy about this, I can already tell you
> now.
Eh, they'll all be AI's anyway and
It's a possibility. Though I haven't coded and benchmarked such an
approach and I don't think I would have the time before the freeze to
take advantage of the sstable format change opportunity.
Still it's sthg that can be explored later. If we can shave a few extra
% then that would always be
If we’re doing this, why don’t we delta encode a vint from some per-sstable
minimum value? I’d expect that to commonly compress to a single byte or so.
> On 23 Jun 2023, at 12:55, Aleksey Yeshchenko wrote:
>
> Distant future people will not be happy about this, I can already tell you
> now.
>
Distant future people will not be happy about this, I can already tell you now.
Sounds like a reasonable improvement to me however.
> On 23 Jun 2023, at 07:22, Berenguer Blasi wrote:
>
> Hi all,
>
> DeletionTime.markedForDeleteAt is a long useconds since Unix Epoch. But I
> noticed that with
Hi all,
DeletionTime.markedForDeleteAt is a long useconds since Unix Epoch. But
I noticed that with 7 bytes we can already encode ~2284 years. We can
either shed the 8th byte, for reduced IO and disk, or can encode some
sentinel values (such as LIVE) as flags there. That would mean reading
an
20 matches
Mail list logo
