On 23 July 2015 at 19:59, Josh Berkus wrote:
> On 07/23/2015 11:18 AM, Robert Haas wrote:
> > Cool. I'm not sure exactly what the right solution is either, but it
> > seems like the current situation could very well lead to degrading
> > index performance over time, with no way to put that right
Tatsuo Ishii wrote:
> > Hm, well, I am not sure that we want to pay the overhead of
> > re-summarization every time we prune a single tuple from a block range.
> > That's going to make vacuum much slower, I assume (without measuring);
> > many page ranges are going to be re-summarized without this
> Hm, well, I am not sure that we want to pay the overhead of
> re-summarization every time we prune a single tuple from a block range.
> That's going to make vacuum much slower, I assume (without measuring);
> many page ranges are going to be re-summarized without this actually
> changing the rang
On 07/23/2015 11:18 AM, Robert Haas wrote:
> Cool. I'm not sure exactly what the right solution is either, but it
> seems like the current situation could very well lead to degrading
> index performance over time, with no way to put that right except to
> rebuild the index completely. So it seems
On Wed, Jul 22, 2015 at 3:20 PM, Alvaro Herrera
wrote:
> Hm, well, I am not sure that we want to pay the overhead of
> re-summarization every time we prune a single tuple from a block range.
> That's going to make vacuum much slower, I assume (without measuring);
> many page ranges are going to be
Robert Haas wrote:
> Maybe I'm confused here, but it seems like the only time
> re-summarization can be needed is when tuples are pruned. The mere
> act of deleting a tuple, even if the delete goes on to commit, doesn't
> create a scenario where re-summarization can work out to a win,
> because t
On Sat, Jul 18, 2015 at 5:11 AM, Alvaro Herrera
wrote:
> Yeah, that's a bit of an open problem: we don't have any mechanism to
> mark a block range as needing resummarization, yet. I don't have any
> great ideas there, TBH. Some options that were discussed but never led
> anywhere:
>
> 1. whenev
Alvaro Herrera wrote:
> Tatsuo Ishii wrote:
>
> > When a transaction aborts, it seems a BRIN index leaves summary data
> > which is not valid any more. Is this an expected behavior? I guess
> > the answer is yes, because it does not affect correctness of a query
> > result, but I would like to ma
Alvaro,
Thank you for the explanation. It's really helpfull.
>> Second question is when the wrong summary data is gone? It seems
>> vacuum does not help. Do I have to recreate the index (or reindex)?
>
> Yeah, that's a bit of an open problem: we don't have any mechanism to
> mark a block range a
Tatsuo Ishii wrote:
> When a transaction aborts, it seems a BRIN index leaves summary data
> which is not valid any more. Is this an expected behavior? I guess
> the answer is yes, because it does not affect correctness of a query
> result, but I would like to make sure.
You're right, that is no
Forgive me if this has been already discussed somewhere.
When a transaction aborts, it seems a BRIN index leaves summary data
which is not valid any more. Is this an expected behavior? I guess
the answer is yes, because it does not affect correctness of a query
result, but I would like to make su
11 matches
Mail list logo
