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 breaks
> src/test/modules/brin.
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 to
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 so that an arbitrary numbe
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 of
> requests can be record
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 TopMemoryCo
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 t
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 c
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 filled. This patch
>> attempts to improve on that. During bri
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 filled. This patch
>> attempts to improve on that. During bri
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
> we're inserting the first
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 autovacu
11 matches
Mail list logo