On Mon, Mar 17, 2025 at 7:06 PM David Rowley wrote:
>
> On Tue, 18 Mar 2025 at 05:49, Masahiko Sawada wrote:
> > I've attached the patch. I added the minimum regression tests for that.
>
> I think the change to vacuumlazy.c is ok. The new test you've added
> creates a table called pvactst2 but th
On Mon, Mar 17, 2025 at 11:54 PM David Rowley wrote:
>
> On Tue, 18 Mar 2025 at 19:34, Masahiko Sawada wrote:
> > I've attached the updated patch.
>
> Looks good to me.
Thank you for reviewing the patch. Pushed (backpatched to v17).
Regards,
--
Masahiko Sawada
Amazon Web Services: https://aws
On Tue, 18 Mar 2025 at 19:34, Masahiko Sawada wrote:
> I've attached the updated patch.
Looks good to me.
David
On Tue, 18 Mar 2025 at 05:49, Masahiko Sawada wrote:
> I've attached the patch. I added the minimum regression tests for that.
I think the change to vacuumlazy.c is ok. The new test you've added
creates a table called pvactst2 but then adds a test that uses the
pvactst table.
Did you mean to ski
On Mon, Mar 10, 2025 at 2:53 AM David Rowley wrote:
>
> On Mon, 10 Mar 2025 at 17:22, Masahiko Sawada wrote:
> > Regarding that patch, we need to note that the lpdead_items is a
> > counter that is not reset in the entire vacuum. Therefore, with
> > maintenance_work_mem = 64kB, once we collect at
On Mon, Mar 10, 2025 at 2:53 AM David Rowley wrote:
>
> On Mon, 10 Mar 2025 at 17:22, Masahiko Sawada wrote:
> > Regarding that patch, we need to note that the lpdead_items is a
> > counter that is not reset in the entire vacuum. Therefore, with
> > maintenance_work_mem = 64kB, once we collect at
On Mon, Mar 10, 2025 at 1:46 AM Masahiko Sawada wrote:
>
> Commit bbf668d66fbf6 (back-patched to v17) lowered the minimum
> maintenance_work_mem to 64kB, but it doesn't work for parallel vacuum
That was done in the first place to make a regression test for a bug
fix easier, but that test never go
On Mon, 10 Mar 2025 at 17:22, Masahiko Sawada wrote:
> Regarding that patch, we need to note that the lpdead_items is a
> counter that is not reset in the entire vacuum. Therefore, with
> maintenance_work_mem = 64kB, once we collect at least one lpdead item,
> we perform a cycle of index vacuuming
On Mon, 10 Mar 2025 at 10:30, David Rowley wrote:
> Could you do something similar to what's in hash_agg_check_limits()
> where we check we've got at least 1 item before bailing before we've
> used up the all the prescribed memory? That seems like a safer coding
> practise as if in the future the
On Sun, Mar 9, 2025 at 7:03 PM David Rowley wrote:
>
> On Mon, 10 Mar 2025 at 10:30, David Rowley wrote:
> > Could you do something similar to what's in hash_agg_check_limits()
> > where we check we've got at least 1 item before bailing before we've
> > used up the all the prescribed memory? Tha
On Sun, Mar 9, 2025 at 9:24 PM John Naylor wrote:
>
> On Mon, Mar 10, 2025 at 1:46 AM Masahiko Sawada wrote:
> >
> > Commit bbf668d66fbf6 (back-patched to v17) lowered the minimum
> > maintenance_work_mem to 64kB, but it doesn't work for parallel vacuum
>
> That was done in the first place to mak
On Mon, 10 Mar 2025 at 07:46, Masahiko Sawada wrote:
> A simple fix is to bump the minimum maintenance_work_mem to 256kB. We
> would break the compatibility for backbranch (i.e. v17) but I guess
> it's unlikely that existing v17 users are using less than 1MB
> maintenance_work_mem (the release not
12 matches
Mail list logo
