Re: [HACKERS] brin autosummarization -- autovacuum "work items"

On Sat, Apr 1, 2017 at 10:09 AM, Alvaro Herrera wrote: > Alvaro Herrera wrote: > > > I also removed the behavior that on index creation the final partial > > block range is always summarized. It's pointless. > > I just pushed this, without this change, because it

Re: [HACKERS] brin autosummarization -- autovacuum "work items"

Alvaro Herrera wrote: > I also removed the behavior that on index creation the final partial > block range is always summarized. It's pointless. I just pushed this, without this change, because it breaks src/test/modules/brin. I still think it's pointless, but it'd require more than one line

Re: [HACKERS] brin autosummarization -- autovacuum "work items"

Robert Haas wrote: > On Tue, Mar 21, 2017 at 4:10 PM, Alvaro Herrera > wrote: > > Well, the number of work items is currently fixed; but if you have many > > BRIN indexes, then you'd overflow (lose requests). By using DSA I am > > making it easy to patch this afterwards

Re: [HACKERS] brin autosummarization -- autovacuum "work items"

On Tue, Mar 21, 2017 at 4:10 PM, Alvaro Herrera wrote: > Well, the number of work items is currently fixed; but if you have many > BRIN indexes, then you'd overflow (lose requests). By using DSA I am > making it easy to patch this afterwards so that an arbitrary number

Re: [HACKERS] brin autosummarization -- autovacuum "work items"

Here's a version of this patch which I consider final. Thanks for your tips on using DSA. No crashes now. I am confused about not needing dsa_attach the second time around. If I do that, the dsa handle has been 0x7f'd, which I don't understand since it is supposed to be allocated in

Re: [HACKERS] brin autosummarization -- autovacuum "work items"

Thomas Munro wrote: > What is your motivation for using DSA? It seems you are creating an > area and then using it to make exactly one allocation of a constant > size known up front to hold your fixed size workitems array. You > don't do any dynamic allocation at runtime, apart from the detail

Re: [HACKERS] brin autosummarization -- autovacuum "work items"

Thomas Munro wrote: > Another thought about this design: Why autovacuum? One reason is that autovacuum is already there, so it's convenient to give it the responsibility for this kind of task. Another reason is that autovacuum is already doing this, via vacuum. I don't see the need to have a

Re: [HACKERS] brin autosummarization -- autovacuum "work items"

On Wed, Mar 1, 2017 at 6:06 PM, Thomas Munro wrote: > On Wed, Mar 1, 2017 at 5:58 PM, Alvaro Herrera > wrote: >> I think one of the most serious issues with BRIN indexes is how they >> don't get updated automatically as the table is

Re: [HACKERS] brin autosummarization -- autovacuum "work items"

On Wed, Mar 1, 2017 at 6:06 PM, Thomas Munro wrote: > On Wed, Mar 1, 2017 at 5:58 PM, Alvaro Herrera > wrote: >> I think one of the most serious issues with BRIN indexes is how they >> don't get updated automatically as the table is

Re: [HACKERS] brin autosummarization -- autovacuum "work items"

On Wed, Mar 1, 2017 at 5:58 PM, Alvaro Herrera 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 >

[HACKERS] brin autosummarization -- autovacuum "work items"

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