glynnbird commented on PR #5603:
URL: https://github.com/apache/couchdb/pull/5603#issuecomment-3255733062

   If you still want to retain 60 buckets, how about:
   
   - 1 bucket a day for 30 days
   - 1 bucket a month for 24 months for changes older than 30 days
   - 1 bucket a year for 5 years for changes older than 30 days + 24 months
   - 1 bucket for everything older than that
   
   30 days + 24 months + 5 years + 1 = 60
   
   
   
   
   On Thu, 4 Sept 2025, 21:59 Nick Vatamaniuc, ***@***.***>
   wrote:
   
   > ***@***.**** commented on this pull request.
   > ------------------------------
   >
   > In src/couch/src/couch_time_seq.erl
   > <https://github.com/apache/couchdb/pull/5603#discussion_r2323536825>:
   >
   > > +%  - With the ?INTERVALS schedule defined below ran 1 update per hour 
for 1M
   > +%    updates starting at year 3000 and ending at year 3114 and obtained:
   > +%      * Less than 10 years of spacing between years at the start: 3000, 
3009, 3018 ...
   > +%      * Ten individual latest days: 3114-01-20 -> 3114-01-30
   > +%      * Seven individual latest months: 3113-07 -> 3114-01
   > +%  - Uncompressed term_to_binary(TSeq) = 920B
   > +%  - RAM flat size erts_debug:flat_size(TSeq) * 
erlang:system_info(wordsize) = 2KB
   > +%
   > +-define(MAX_BIN_COUNT, 60).
   > +
   > +-define(H, 3600).
   > +-define(D, ?H * 24).
   > +-define(M, ?D * 30).
   > +-define(Y, ?D * 365).
   > +%% erlfmt-ignore
   > +-define(INTERVALS, [
   >
   > sure, I get that, but for example we can't do "3 months" and the ability
   > to do "16 years" is a bit outlandish to me. Yes, agree that per-db state is
   > tricky (and the security object is a bad precedent since clustering).
   >
   > 3 months already works; I ran a simulation with 1 update per hour for 1
   > million hours:
   >
   >    - Can do 11 days down to individual days:
   >    30,29,28,27,26,25,24,23,22,21,20 then can do another 10 but skipping 
one or
   >    two days in between.
   >    - Can do 7 months down to individual months: 01 ,12,11,10,09,08,07,
   >    then it can do 3 or 4 more months skipping one or two in between.
   >    - Left less resolution for the years: about 3 individual years, then 4
   >    more skipping 2 or 3 in between. Then switches to decades and such and
   >    probably doesn't matter as much.
   >
   >    3000-01-01T00:00:00Z -> 82176
   >    3009-05-18T00:00:00Z -> 83712
   >    3018-12-05T00:00:00Z -> 85584
   >    3028-09-09T00:00:00Z -> 82416
   >    3038-02-03T00:00:00Z -> 85488
   >    3047-11-05T00:00:00Z -> 82704
   >    3057-04-12T00:00:00Z -> 82944
   >    3066-09-28T00:00:00Z -> 85872
   >    3076-07-15T00:00:00Z -> 83520
   >    3086-01-24T00:00:00Z -> 41472
   >    3090-10-18T00:00:00Z -> 41472
   >    3095-07-12T00:00:00Z -> 41760
   >    3100-04-17T00:00:00Z -> 41472
   >    3105-01-09T00:00:00Z -> 20736
   >    3107-05-23T00:00:00Z -> 20736
   >    3109-10-03T00:00:00Z -> 10368
   >    3110-12-09T00:00:00Z -> 10368
   >    3112-02-14T00:00:00Z -> 5184
   >    3112-09-17T00:00:00Z -> 3456
   >    3113-02-08T00:00:00Z -> 864
   >    3113-03-16T00:00:00Z -> 864
   >    3113-04-21T00:00:00Z -> 864
   >    3113-05-27T00:00:00Z -> 864
   >    3113-07-02T00:00:00Z -> 864
   >    3113-08-07T00:00:00Z -> 288
   >    3113-08-19T00:00:00Z -> 288
   >    3113-08-31T00:00:00Z -> 288
   >    3113-09-12T00:00:00Z -> 288
   >    3113-09-24T00:00:00Z -> 288
   >    3113-10-06T00:00:00Z -> 288
   >    3113-10-18T00:00:00Z -> 288
   >    3113-10-30T00:00:00Z -> 288
   >    3113-11-11T00:00:00Z -> 288
   >    3113-11-23T00:00:00Z -> 288
   >    3113-12-05T00:00:00Z -> 288
   >    3113-12-17T00:00:00Z -> 288
   >    3113-12-29T00:00:00Z -> 96
   >    3114-01-02T00:00:00Z -> 48
   >    3114-01-04T00:00:00Z -> 48
   >    3114-01-06T00:00:00Z -> 48
   >    3114-01-08T00:00:00Z -> 48
   >    3114-01-10T00:00:00Z -> 48
   >    3114-01-12T00:00:00Z -> 48
   >    3114-01-14T00:00:00Z -> 48
   >    3114-01-16T00:00:00Z -> 48
   >    3114-01-18T00:00:00Z -> 48
   >    3114-01-20T00:00:00Z -> 24
   >    3114-01-21T00:00:00Z -> 24
   >    3114-01-22T00:00:00Z -> 24
   >    3114-01-23T00:00:00Z -> 24
   >    3114-01-24T00:00:00Z -> 24
   >    3114-01-25T00:00:00Z -> 24
   >    3114-01-26T00:00:00Z -> 24
   >    3114-01-27T00:00:00Z -> 24
   >    3114-01-28T00:00:00Z -> 24
   >    3114-01-29T00:00:00Z -> 24
   >    3114-01-30T00:00:00Z -> 6
   >    3114-01-30T06:00:00Z -> 6
   >    3114-01-30T12:00:00Z -> 3
   >    3114-01-30T15:00:00Z -> 1
   >
   > —
   > Reply to this email directly, view it on GitHub
   > <https://github.com/apache/couchdb/pull/5603#discussion_r2323536825>, or
   > unsubscribe
   > 
<https://github.com/notifications/unsubscribe-auth/AAFKMRIIXAN3FYP4IECJV4T3RCR2DAVCNFSM6AAAAACCBERWLWVHI2DSMVQWIX3LMV43YUDVNRWFEZLROVSXG5CSMV3GSZLXHMZTCOBXGIZTEMBSGA>
   > .
   > You are receiving this because you were mentioned.Message ID:
   > ***@***.***>
   >
   


-- 
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: notifications-unsubscr...@couchdb.apache.org

For queries about this service, please contact Infrastructure at:
us...@infra.apache.org

Reply via email to