Feedback-ID: ia2694551:Fastmail
Date: Mon, 4 Mar 2024 12:52:47 +0100
From: 'Alvaro Herrera' <alvherre@alvh.no-ip.org>
To: "Hayato Kuroda (Fujitsu)" <kuroda.hayato@fujitsu.com>
Cc: 
	"'pgsql-hackers@lists.postgresql.org'" <pgsql-hackers@lists.postgresql.org>
Subject: Re: Some shared memory chunks are allocated even if related
 processes won't start
Message-ID: <202403041152.fl4psozsstnt@alvherre.pgsql>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: 
 <TYCPR01MB12077D982922BFD6FE8706758F5232@TYCPR01MB12077.jpnprd01.prod.outlook.com>
Archived-At: 
 <https://www.postgresql.org/message-id/202403041152.fl4psozsstnt%40alvherre.pgsql>
Precedence: bulk

On 2024-Mar-04, Hayato Kuroda (Fujitsu) wrote:

> However, the second idea is still valid, which allows the allocation
> of shared memory dynamically. This is a bit efficient for the system
> which tuples won't be frozen. Thought?

I think it would be worth allocating AutoVacuumShmem->av_workItems using
dynamic shmem allocation, particularly to prevent workitems from being
discarded just because the array is full¹; but other than that, the
struct is just 64 bytes long so I doubt it's useful to allocate it
dynamically.

¹ I mean, if the array is full, just allocate another array, point to it
from the original one, and keep going.

-- 
Álvaro Herrera         PostgreSQL Developer  —  https://www.EnterpriseDB.com/
"The problem with the facetime model is not just that it's demoralizing, but
that the people pretending to work interrupt the ones actually working."
                  -- Paul Graham, http://www.paulgraham.com/opensource.html