Re: brin autosummarization -- autovacuum "work items"

On Wed, Mar 1, 2017 at 6:06 PM, Thomas Munro
<thomas(dot)munro(at)enterprisedb(dot)com> wrote:
> On Wed, Mar 1, 2017 at 5:58 PM, Alvaro Herrera <alvherre(at)2ndquadrant(dot)com> wrote:
>> I think one of the most serious issues with BRIN indexes is how they
>> don't get updated automatically as the table is filled. This patch
>> attempts to improve on that. During brininsert() time, we check whether
>> we're inserting the first item on the first page in a range. If we are,
>> request autovacuum to do a summarization run on that table. This is
>> dependent on a new reloption for BRIN called "autosummarize", default
>> off.
>
> Nice.

Another thought about this design: Why autovacuum?

Obviously we don't want to get to the point where you start up
PostgreSQL and see 25 llines like BRIN SummarizationLauncher started,
Foo Launcher started, Bar Launcher started, ... but perhaps there is a
middle ground between piling all the background work into the
autovacuum framework, and making new dedicated launchers and workers
for each thing.

Is there some way we could turn this kind of maintenance work into a
'task' (insert better word) that can be scheduled to run
asynchronously by magic workers, so that you don't have to supply a
whole worker and main loop and possibly launcher OR jam new
non-vacuum-related work into the vacuum machinery, for each thing like
this that someone decides to invent?

--
Thomas Munro
http://www.enterprisedb.com