Hi,
On 2023-11-15 16:21:45 -0500, Melanie Plageman wrote:
> On Tue, Nov 14, 2023 at 7:15 PM Andres Freund wrote:
> > On 2023-11-14 07:46:10 -0500, Melanie Plageman wrote:
> > > > FreeSpaceMapVacuumRange()'s comment says:
> > > > * As above, but assume that only heap pages between start and end-1
On Thu, Nov 16, 2023 at 3:29 PM Robert Haas wrote:
>
> On Wed, Nov 15, 2023 at 6:17 PM Andres Freund wrote:
> > Thoughts on whether to backpatch? It'd probably be at least a bit painful,
> > there have been a lot of changes in the surrounding code in the last 5
> > years.
>
> I guess the main po
On Thu, Nov 16, 2023 at 3:49 PM Andres Freund wrote:
> I think the main reason it's not all that bad, even when hitting this path, is
> that one stall every 8GB just isn't that much and that the stalls aren't that
> long - the leaf page fsm updates don't use the strategy, so they're still
> somewh
Hi,
On 2023-11-16 15:29:38 -0500, Robert Haas wrote:
> On Wed, Nov 15, 2023 at 6:17 PM Andres Freund wrote:
> > Thoughts on whether to backpatch? It'd probably be at least a bit painful,
> > there have been a lot of changes in the surrounding code in the last 5
> > years.
>
> I guess the main p
On Wed, Nov 15, 2023 at 6:17 PM Andres Freund wrote:
> Thoughts on whether to backpatch? It'd probably be at least a bit painful,
> there have been a lot of changes in the surrounding code in the last 5 years.
I guess the main point that I'd make here is that we shouldn't
back-patch because it's
Hi,
On 2023-11-15 16:32:48 -0500, Robert Haas wrote:
> On Mon, Nov 13, 2023 at 8:26 PM Andres Freund wrote:
> > I think this undersells the situation a bit. We right now do
> > FreeSpaceMapVacuumRange() for 8GB of data (VACUUM_FSM_EVERY_PAGES) in the
> > main
> > fork, while holding an exclusive
On Mon, Nov 13, 2023 at 8:26 PM Andres Freund wrote:
> I think this undersells the situation a bit. We right now do
> FreeSpaceMapVacuumRange() for 8GB of data (VACUUM_FSM_EVERY_PAGES) in the main
> fork, while holding an exclusive page level lock.
That sounds fairly horrific?
--
Robert Haas
ED
On Tue, Nov 14, 2023 at 7:15 PM Andres Freund wrote:
>
> Hi,
>
> On 2023-11-14 07:46:10 -0500, Melanie Plageman wrote:
> > > FreeSpaceMapVacuumRange()'s comment says:
> > > * As above, but assume that only heap pages between start and end-1
> > > inclusive
> > > * have new free-space informatio
Hi,
On 2023-11-14 07:46:10 -0500, Melanie Plageman wrote:
> > FreeSpaceMapVacuumRange()'s comment says:
> > * As above, but assume that only heap pages between start and end-1
> > inclusive
> > * have new free-space information, so update only the upper-level slots
> > * covering that block ra
On Mon, Nov 13, 2023 at 8:26 PM Andres Freund wrote:
> On 2023-11-13 17:13:32 -0500, Melanie Plageman wrote:
> > diff --git a/src/backend/access/heap/vacuumlazy.c
> > b/src/backend/access/heap/vacuumlazy.c
> > index 6985d299b2..8b729828ce 100644
> > --- a/src/backend/access/heap/vacuumlazy.c
> >
Hi,
On 2023-11-13 17:13:32 -0500, Melanie Plageman wrote:
> I noticed that in lazy_scan_heap(), when there are no indexes on the
> table being vacuumed, we don't release the lock on the heap page buffer
> before vacuuming the freespace map. Other call sites of
> FreeSpaceMapVacuumRange() hold no s
Hi,
I noticed that in lazy_scan_heap(), when there are no indexes on the
table being vacuumed, we don't release the lock on the heap page buffer
before vacuuming the freespace map. Other call sites of
FreeSpaceMapVacuumRange() hold no such lock. It seems like a waste to
hold a lock we don't need.
12 matches
Mail list logo
