On Wed, Mar 1, 2017 at 6:06 PM, Thomas Munro <thomas.mu...@enterprisedb.com> wrote: > On Wed, Mar 1, 2017 at 5:58 PM, Alvaro Herrera <alvhe...@2ndquadrant.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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
