Re: Questions/Observations related to Gist vacuum
Dilip Kumar <dilipbalaut@gmail.com>
From: Dilip Kumar <dilipbalaut@gmail.com>
To: Amit Kapila <amit.kapila16@gmail.com>
Cc: Heikki Linnakangas <hlinnaka@iki.fi>,
Andrey Borodin <x4mmm@yandex-team.ru>, PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>
Date: 2019-10-17T04:21:29Z
Lists: pgsql-hackers
On Thu, Oct 17, 2019 at 9:15 AM Amit Kapila <amit.kapila16@gmail.com> wrote: > > On Wed, Oct 16, 2019 at 7:21 PM Heikki Linnakangas <hlinnaka@iki.fi> wrote: > > > > On 16 October 2019 12:57:03 CEST, Amit Kapila <amit.kapila16@gmail.com> wrote: > > >On Tue, Oct 15, 2019 at 7:13 PM Heikki Linnakangas <hlinnaka@iki.fi> > > >wrote: > > >> All things > > >> considered, I'm not sure which is better. > > > > > >Yeah, this is a tough call to make, but if we can allow it to delete > > >the pages in bulkdelete conditionally for parallel vacuum workers, > > >then it would be better. > > > > Yeah, if it's needed for parallel vacuum, maybe that tips the scale. > > > > makes sense. I think we can write a patch for it and prepare the > parallel vacuum patch on top of it. Once the parallel vacuum is in a > committable shape, we can commit the gist-index related patch first > followed by parallel vacuum patch. +1 I can write a patch for the same. > > Hopefully, multi-pass vacuums are rare in practice. And we should lift the current 1 GB limit on the dead TID array, replacing it with something more compact and expandable, to make multi-pass vacuums even more rare. So I don't think we need to jump through many hoops to optimize the multi-pass case. > > > > Yeah, that will be a good improvement. +1 -- Regards, Dilip Kumar EnterpriseDB: http://www.enterprisedb.com
Commits
-
Delete empty pages in each pass during GIST VACUUM.
- 4e514c6180fb 13.0 landed
-
Fix memory leak introduced in commit 7df159a620.
- 62f4dd3796da 12.1 landed
- 70a6c37d524c 13.0 landed
-
Delete empty pages during GiST VACUUM.
- 7df159a620b7 12.0 cited