git/list[1] front-page[2] threads[3] people[4] search[5] about
 

Re: [PATCH v2 2/5] reftable/stack: add function to check if optimization is required

From
Karthik Nayak <karthik.188@gmail.com>
Date
Nov 6, 2025, 08:18 UTC
Message-ID
<CAOLa=ZTTfaGsQrK-e5c9h4nMk656GM0Mue6Ytie4GOes4n_-5g@mail.gmail.com>
In-Reply-To
<xmqqms50l594.fsf@gitster.g>
Junio C Hamano <gitster@pobox.com> writes:
Show 84 quoted lines
> Karthik Nayak <karthik.188@gmail.com> writes:
>
>> Junio C Hamano <gitster@pobox.com> writes:
>>
>>> Karthik Nayak <karthik.188@gmail.com> writes:
>>>
>>>> The reftable backend performs auto-compaction as part of its regular
>>>> flow, which is required to keep the number of tables part of a stack at
>>>> bay. This allows it to stay optimized.
>>>
>>> Sounds very sensible.
>>>
>>>> Compaction can also be triggered voluntarily by the user via the 'git
>>>> pack-refs' or the 'git refs optimize' command. However, currently there
>>>> is no way for the user to check if optimization is required without
>>>> actually performing it.
>>>
>>> Sounds very sensible goal.
>>>
>>> But where is the existing logic to decide when it needs to
>>> auto-compact, performed as part of its regular flow?
>>>
>>> After reading "the reftable machinery already decides when it needs
>>> to compact and does so" plus "but the logic to decide is not made
>>> available to users", I would have expected for this patch to extract
>>> such an existing logic or otherwise make it available to new callers
>>> so that things like "gc --auto" can call it, but the diffstat shows
>>> mostly additions, which does not give readers any confidence in the
>>> new function that answers "do we need compaction?".  It would give
>>> _an_ answer, but there is no clue if the answer it gives is the same
>>> answer as the existing logic that decides when to compact as part of
>>> the regular operation.
>>>
>>> I am puzzled.
>>>
>>>> +int reftable_stack_compaction_required(struct reftable_stack *st,
>>>> +				       bool use_heuristics,
>>>> +				       bool *required)
>>>> +{
>>>> +	struct segment seg;
>>>> +	int err = 0;
>>>> +
>>>> +	if (st->merged->tables_len < 2) {
>>>> +		*required = false;
>>>> +		return 0;
>>>> +	}
>>>> +
>>>> +	if (!use_heuristics) {
>>>> +		*required = true;
>>>> +		return 0;
>>>> +	}
>>>> +
>>>> +	err = stack_segments_for_compaction(st, &seg);
>>>> +	if (err)
>>>> +		return err;
>>>> +
>>>> +	*required = segment_size(&seg) > 0;
>>>> +	return 0;
>>>> +}
>>>
>>> Specifically, where is the above logic come from?  Is it duplicating
>>> an existing logic but that code is hard to separate out into this
>>> helper?
>>>
>>
>> Good question.
>>
>> Most of this logic is already part of 'reftable_stack_auto_compact()'.
>> We also have another similar function 'reftable_stack_compact_all()'.
>> The former is used for compaction based on heuristics and the latter is
>> for compacting all tables into one. In the refs subsystem usage of
>> heuristics is denoted by the usage of the 'REFS_OPTIMIZE_AUTO' flag.
>>
>> The function we're introducing allows users to explicitly mention if
>> they want to use heuristics or not. This allows us to differentiate
>> between the two modes. The result of which is that this uses intertwined
>> logic of the two existing functions. Hence we can't extract any code out.
>>
>> I'll add this information in the commit message.
>
> You mean you already have two duplicate implementations whose
> definition of "when should we compact?" can drift apart over time
> (worse, they may already be subtly different), and you are adding
> yet another one?
More like we have two functions:
1. compact all tables into one
2. compact based on heuristics
This function oversees logic from both.
Show 5 quoted lines
> Instead of describing such an insanity in the commit message, can we
> refactor to have a single central logic that is used from three
> places?
>
> Thanks.

You're right though, I did manage to extract out the common code and will send in a new version. Thanks for the push.

- Karthik
Previous: Junio C HamanoNext: Karthik Nayak
Message 30 of 57 in “maintenance: add an 'is-needed' subcommand”
  1. 0/5 maintenance: add an 'is-needed' subcommandKarthik Nayak, Oct 31, 2025
  2. 1/5 reftable/stack: return stack segments directlyKarthik Nayak, Oct 31, 2025
  3. Justin ToblerOct 31, 2025
  4. Karthik NayakNov 3, 2025
  5. Justin ToblerNov 3, 2025
  6. 2/5 reftable/stack: add function to check if optimization is requiredKarthik Nayak, Oct 31, 2025
  7. Justin ToblerOct 31, 2025
  8. Junio C HamanoOct 31, 2025
  9. Karthik NayakNov 3, 2025
  10. Karthik NayakNov 3, 2025
  11. Justin ToblerNov 3, 2025
  12. Patrick SteinhardtNov 3, 2025
  13. Karthik NayakNov 3, 2025
  14. 3/5 refs: add a `optimize_required` field to `struct ref_storage_be`Karthik Nayak, Oct 31, 2025
  15. 4/5 maintenance: add checking logic in `pack_refs_condition()`Karthik Nayak, Oct 31, 2025
  16. Patrick SteinhardtNov 3, 2025
  17. Karthik NayakNov 3, 2025
  18. 5/5 maintenance: add 'is-needed' subcommandKarthik Nayak, Oct 31, 2025
  19. Patrick SteinhardtNov 3, 2025
  20. Karthik NayakNov 3, 2025
  21. Patrick SteinhardtNov 4, 2025
  22. Karthik NayakNov 4, 2025
  23. 0/5 maintenance: add an 'is-needed' subcommandKarthik Nayak, Nov 4, 2025
  24. 1/5 reftable/stack: return stack segments directlyKarthik Nayak, Nov 4, 2025
  25. 3/5 refs: add a `optimize_required` field to `struct ref_storage_be`Karthik Nayak, Nov 4, 2025
  26. 2/5 reftable/stack: add function to check if optimization is requiredKarthik Nayak, Nov 4, 2025
  27. Junio C HamanoNov 4, 2025
  28. Karthik NayakNov 5, 2025
  29. Junio C HamanoNov 5, 2025
  30. Karthik NayakNov 6, 2025
  31. 4/5 maintenance: add checking logic in `pack_refs_condition()`Karthik Nayak, Nov 4, 2025
  32. 5/5 maintenance: add 'is-needed' subcommandKarthik Nayak, Nov 4, 2025
  33. Junio C HamanoNov 4, 2025
  34. Karthik NayakNov 5, 2025
  35. 0/5 maintenance: add an 'is-needed' subcommandKarthik Nayak, Nov 6, 2025
  36. 1/5 reftable/stack: return stack segments directlyKarthik Nayak, Nov 6, 2025
  37. 2/5 reftable/stack: add function to check if optimization is requiredKarthik Nayak, Nov 6, 2025
  38. Junio C HamanoNov 6, 2025
  39. Patrick SteinhardtNov 7, 2025
  40. 3/5 refs: add a `optimize_required` field to `struct ref_storage_be`Karthik Nayak, Nov 6, 2025
  41. 4/5 maintenance: add checking logic in `pack_refs_condition()`Karthik Nayak, Nov 6, 2025
  42. Patrick SteinhardtNov 6, 2025
  43. Karthik NayakNov 6, 2025
  44. Junio C HamanoNov 6, 2025
  45. Karthik NayakNov 7, 2025
  46. Junio C HamanoNov 7, 2025
  47. Karthik NayakNov 7, 2025
  48. 5/5 maintenance: add 'is-needed' subcommandKarthik Nayak, Nov 6, 2025
  49. Patrick SteinhardtNov 6, 2025
  50. Karthik NayakNov 6, 2025
  51. 0/5 maintenance: add an 'is-needed' subcommandKarthik Nayak, Nov 8, 2025
  52. 1/5 reftable/stack: return stack segments directlyKarthik Nayak, Nov 8, 2025
  53. 2/5 reftable/stack: add function to check if optimization is requiredKarthik Nayak, Nov 8, 2025
  54. 3/5 refs: add a `optimize_required` field to `struct ref_storage_be`Karthik Nayak, Nov 8, 2025
  55. 4/5 maintenance: add checking logic in `pack_refs_condition()`Karthik Nayak, Nov 8, 2025
  56. 5/5 maintenance: add 'is-needed' subcommandKarthik Nayak, Nov 8, 2025
  57. Patrick SteinhardtNov 10, 2025

Read the whole thread, see it on lore, or plain text.

$ cat FOOTERMessages come from the public archive at lore.kernel.org/git, fetched every hour. The front page is chosen and written each morning by an AI editor and can be wrong; the threads themselves are the record. About and API. For agents: an MCP server at https://gitlist.dev/mcp, and any thread, story or person page as Markdown by adding .md to its URL (or sending Accept: text/markdown). Details in /llms.txt.