Re: Vacuum: allow usage of more than 1GB of work mem
Claudio Freire <klaussfreire@gmail.com>
From: Claudio Freire <klaussfreire@gmail.com>
To: Heikki Linnakangas <hlinnaka@iki.fi>
Cc: PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>
Date: 2018-04-07T00:00:20Z
Lists: pgsql-hackers
On Fri, Apr 6, 2018 at 5:25 PM, Claudio Freire <klaussfreire@gmail.com> wrote: > On Fri, Apr 6, 2018 at 10:39 AM, Heikki Linnakangas <hlinnaka@iki.fi> wrote: >> On 06/04/18 01:59, Claudio Freire wrote: >>> >>> The iteration interface, however, seems quite specific for the use >>> case of vacuumlazy, so it's not really a good abstraction. >> >> >> Can you elaborate? It does return the items one block at a time. Is that >> what you mean by being specific for vacuumlazy? I guess that's a bit >> special, but if you imagine some other users for this abstraction, it's >> probably not that unusual. For example, if we started using it in bitmap >> heap scans, a bitmap heap scan would also want to get the TIDs one block >> number at a time. > > But you're also tying the caller to the format of the buffer holding > those TIDs, for instance. Why would you, when you can have an > interface that just iterates TIDs and let the caller store them > if/however they want? > > I do believe a pure iterator interface is a better interface. Between the b-tree or not discussion and the refactoring to separate the code, I don't think we'll get this in the next 24hs. So I guess we'll have ample time to poner on both issues during the next commit fest.
Commits
-
Prefetch blocks during lazy vacuum's truncation scan
- 7e26e02eec90 10.0 landed
-
Explain unaccounted for space in pgstattuple.
- 71f996d22125 10.0 cited