git@vger.kernel.org mailing list mirror (one of many)
 help / color / mirror / code / Atom feed
From: Justin Tobler <jltobler@gmail.com>
To: Karthik Nayak <karthik.188@gmail.com>
Cc: git@vger.kernel.org
Subject: Re: [PATCH 2/5] reftable/stack: add function to check if optimization is required
Date: Fri, 31 Oct 2025 12:02:25 -0500	[thread overview]
Message-ID: <tdgxvocyp2armupgbti2wnbjphdvidooddbdyrynmdokjgqr3o@tzrbu5lcgipt> (raw)
In-Reply-To: <20251031-562-add-sub-command-to-check-if-maintenance-is-needed-v1-2-a03d53e28d0e@gmail.com>

On 25/10/31 03:22PM, Karthik Nayak wrote:
> 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.
> 
> 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.
> 
> Add and expose `reftable_stack_compaction_required()` which will allow
> users to check if the reftable backend can be optimized.
> 
> Signed-off-by: Karthik Nayak <karthik.188@gmail.com>
> ---
>  reftable/reftable-stack.h       |  5 +++++
>  reftable/stack.c                | 25 +++++++++++++++++++++++++
>  t/unit-tests/u-reftable-stack.c | 12 ++++++++++--
>  3 files changed, 40 insertions(+), 2 deletions(-)
> 
> diff --git a/reftable/reftable-stack.h b/reftable/reftable-stack.h
> index d70fcb705d..a875149439 100644
> --- a/reftable/reftable-stack.h
> +++ b/reftable/reftable-stack.h
> @@ -123,6 +123,11 @@ struct reftable_log_expiry_config {
>  int reftable_stack_compact_all(struct reftable_stack *st,
>  			       struct reftable_log_expiry_config *config);
>  
> +/* Check if compaction is required. */
> +int reftable_stack_compaction_required(struct reftable_stack *st,
> +				       bool use_heuristics,
> +				       bool *required);
> +
>  /* heuristically compact unbalanced table stack. */
>  int reftable_stack_auto_compact(struct reftable_stack *st);
>  
> diff --git a/reftable/stack.c b/reftable/stack.c
> index 49387f9344..18fa41cd5c 100644
> --- a/reftable/stack.c
> +++ b/reftable/stack.c
> @@ -1647,6 +1647,31 @@ static int stack_segments_for_compaction(struct reftable_stack *st,
>  	return 0;
>  }
>  
> +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;
> +	}

Both `reftable_stack_auto_compact()` and `suggest_compaction_segement()`
already check if the stack has less than two tables. I wonder if we can
avoid having multiple of these checks by instead having a single one at
the start of `stack_segements_for_compaction()`?

> +	if (!use_heuristics) {
> +		*required = true;
> +		return 0;
> +	}

Is there a reason we would want to skip validating the geometric
sequence and just assume it compaction is required?

> +
> +	err = stack_segments_for_compaction(st, &seg);
> +	if (err)
> +		return err;
> +
> +	*required = segment_size(&seg) > 0;

As mentioned on the previous patch, I wonder if we could just return the
number of tables in the compaction segment as part of
`stack_segments_for_compaction()`. A negative value could indicate an
error. All other values would reflect the number of tables to be
compacted.

This way callers interested in whether compaction should be performed
could just do: stack_segments_for_compaction > 0. We could maybe avoid
having a separate function like we do here and just expose
`stack_segments_for_compaction()`.

-Justin


  reply	other threads:[~2025-10-31 17:03 UTC|newest]

Thread overview: 57+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-10-31 14:22 [PATCH 0/5] maintenance: add an 'is-needed' subcommand Karthik Nayak
2025-10-31 14:22 ` [PATCH 1/5] reftable/stack: return stack segments directly Karthik Nayak
2025-10-31 16:22   ` Justin Tobler
2025-11-03 15:05     ` Karthik Nayak
2025-11-03 18:03       ` Justin Tobler
2025-10-31 14:22 ` [PATCH 2/5] reftable/stack: add function to check if optimization is required Karthik Nayak
2025-10-31 17:02   ` Justin Tobler [this message]
2025-10-31 18:17     ` Junio C Hamano
2025-11-03 16:20       ` Karthik Nayak
2025-11-03 15:51     ` Karthik Nayak
2025-11-03 17:59       ` Justin Tobler
2025-11-03 14:00   ` Patrick Steinhardt
2025-11-03 16:35     ` Karthik Nayak
2025-10-31 14:22 ` [PATCH 3/5] refs: add a `optimize_required` field to `struct ref_storage_be` Karthik Nayak
2025-10-31 14:22 ` [PATCH 4/5] maintenance: add checking logic in `pack_refs_condition()` Karthik Nayak
2025-11-03 14:00   ` Patrick Steinhardt
2025-11-03 17:04     ` Karthik Nayak
2025-10-31 14:22 ` [PATCH 5/5] maintenance: add 'is-needed' subcommand Karthik Nayak
2025-11-03 14:00   ` Patrick Steinhardt
2025-11-03 17:18     ` Karthik Nayak
2025-11-04  5:54       ` Patrick Steinhardt
2025-11-04  8:28         ` Karthik Nayak
2025-11-04  8:43 ` [PATCH v2 0/5] maintenance: add an " Karthik Nayak
2025-11-04  8:43   ` [PATCH v2 1/5] reftable/stack: return stack segments directly Karthik Nayak
2025-11-04  8:43   ` [PATCH v2 2/5] reftable/stack: add function to check if optimization is required Karthik Nayak
2025-11-04 20:26     ` Junio C Hamano
2025-11-05 14:11       ` Karthik Nayak
2025-11-05 18:10         ` Junio C Hamano
2025-11-06  8:18           ` Karthik Nayak
2025-11-04  8:43   ` [PATCH v2 3/5] refs: add a `optimize_required` field to `struct ref_storage_be` Karthik Nayak
2025-11-04  8:43   ` [PATCH v2 4/5] maintenance: add checking logic in `pack_refs_condition()` Karthik Nayak
2025-11-04  8:44   ` [PATCH v2 5/5] maintenance: add 'is-needed' subcommand Karthik Nayak
2025-11-04 15:43   ` [PATCH v2 0/5] maintenance: add an " Junio C Hamano
2025-11-05 14:00     ` Karthik Nayak
2025-11-06  8:22 ` [PATCH v3 " Karthik Nayak
2025-11-06  8:22   ` [PATCH v3 1/5] reftable/stack: return stack segments directly Karthik Nayak
2025-11-06  8:22   ` [PATCH v3 2/5] reftable/stack: add function to check if optimization is required Karthik Nayak
2025-11-06 18:18     ` Junio C Hamano
2025-11-07  6:06       ` Patrick Steinhardt
2025-11-06  8:22   ` [PATCH v3 3/5] refs: add a `optimize_required` field to `struct ref_storage_be` Karthik Nayak
2025-11-06  8:22   ` [PATCH v3 4/5] maintenance: add checking logic in `pack_refs_condition()` Karthik Nayak
2025-11-06 11:58     ` Patrick Steinhardt
2025-11-06 13:04       ` Karthik Nayak
2025-11-06 15:24       ` Junio C Hamano
2025-11-07 15:58         ` Karthik Nayak
2025-11-07 16:41           ` Junio C Hamano
2025-11-07 15:58         ` Karthik Nayak
2025-11-06  8:22   ` [PATCH v3 5/5] maintenance: add 'is-needed' subcommand Karthik Nayak
2025-11-06 12:02     ` Patrick Steinhardt
2025-11-06 13:07       ` Karthik Nayak
2025-11-08 21:51 ` [PATCH v4 0/5] maintenance: add an " Karthik Nayak
2025-11-08 21:51   ` [PATCH v4 1/5] reftable/stack: return stack segments directly Karthik Nayak
2025-11-08 21:51   ` [PATCH v4 2/5] reftable/stack: add function to check if optimization is required Karthik Nayak
2025-11-08 21:51   ` [PATCH v4 3/5] refs: add a `optimize_required` field to `struct ref_storage_be` Karthik Nayak
2025-11-08 21:51   ` [PATCH v4 4/5] maintenance: add checking logic in `pack_refs_condition()` Karthik Nayak
2025-11-08 21:51   ` [PATCH v4 5/5] maintenance: add 'is-needed' subcommand Karthik Nayak
2025-11-10  6:46   ` [PATCH v4 0/5] maintenance: add an " Patrick Steinhardt

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: http://vger.kernel.org/majordomo-info.html

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=tdgxvocyp2armupgbti2wnbjphdvidooddbdyrynmdokjgqr3o@tzrbu5lcgipt \
    --to=jltobler@gmail.com \
    --cc=git@vger.kernel.org \
    --cc=karthik.188@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://80x24.org/mirrors/git.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).