On Tue, Apr 21, 2015 at 05:07:52PM -0400, Peter Eisentraut wrote: > On 4/21/15 4:45 PM, Jim Nasby wrote: > > This comment made me wonder... has anyone considered handing the pruning > > work off to a bgworker, at least for SELECTs? That means the selects > > themselves wouldn't be burdened by the actual prune work, only in > > notifying the bgworker. While that's not going to be free, presumably > > it's a lot cheaper... > > The nice thing about having foreground queries to the light cleanup is > that they can work in parallel and naturally hit the interesting parts > of the table first. > > In order for a background worker to keep up with some of the workloads > that have been presented as counterexamples, you'd need multiple > background workers operating in parallel and preferring to work on > certain parts of a table. That would require a lot more sophisticated > job management than we currently have for, say, autovacuum.
Well, the visibility map tells us where _not_ to clean up, so using another map to tell use _where_ to cleanup might make sense. However, the density of the map might be low enough that a list makes more sense, as you suggested. -- Bruce Momjian <br...@momjian.us> http://momjian.us EnterpriseDB http://enterprisedb.com + Everyone has their own god. + -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers