Re: Turning off HOT/Cleanup sometimes

Поиск
Список
Период
Сортировка
От Bruce Momjian
Тема Re: Turning off HOT/Cleanup sometimes
Дата
Msg-id 20150422180503.GC13362@momjian.us
обсуждение исходный текст
Ответ на Re: Turning off HOT/Cleanup sometimes  (Peter Eisentraut <peter_e@gmx.net>)
Список pgsql-hackers
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  <bruce@momjian.us>        http://momjian.us EnterpriseDB
http://enterprisedb.com
 + Everyone has their own god. +



В списке pgsql-hackers по дате отправления:

Предыдущее
От: Payal Singh
Дата:
Сообщение: Re: Idea: closing the loop for "pg_ctl reload"
Следующее
От: Robert Haas
Дата:
Сообщение: Re: Custom/Foreign-Join-APIs (Re: [v9.5] Custom Plan API)