Re: Add index scan progress to pg_stat_progress_vacuum

Hi,

On 2022-03-16 21:47:49 +0000, Imseih (AWS), Sami wrote:
> From 85c47dfb3bb72f764b9052e74a7282c19ebd9898 Mon Sep 17 00:00:00 2001
> From: "Sami Imseih (AWS)" <simseih(at)amazon(dot)com>
> Date: Wed, 16 Mar 2022 20:39:52 +0000
> Subject: [PATCH 1/1] Add infrastructure for parallel progress reporting
>
> Infrastructure to allow a parallel worker to report
> progress. In a PARALLEL command, the workers and
> leader can report progress using a new pgstat_progress
> API.

What happens if we run out of memory for hashtable entries?

> +void
> +pgstat_progress_update_param_parallel(int leader_pid, int index, int64 val)
> +{
> + ProgressParallelEntry *entry;
> + bool found;
> +
> + LWLockAcquire(ProgressParallelLock, LW_EXCLUSIVE);
> +
> + entry = (ProgressParallelEntry *) hash_search(ProgressParallelHash, &leader_pid, HASH_ENTER, &found);
> +
> + /*
> + * If the entry is not found, set the value for the index'th member,
> + * else increment the current value of the index'th member.
> + */
> + if (!found)
> + entry->st_progress_param[index] = val;
> + else
> + entry->st_progress_param[index] += val;
> +
> + LWLockRelease(ProgressParallelLock);
> +}

I think that's an absolute no-go. Adding locking to progress reporting,
particularly a single central lwlock, is going to *vastly* increase the
overhead incurred by progress reporting.

Greetings,

Andres Freund