On 23 July 2015 at 19:59, Josh Berkus j...@agliodbs.com 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
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 range.
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
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 there
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
alvhe...@2ndquadrant.com 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
On Sat, Jul 18, 2015 at 5:11 AM, Alvaro Herrera
alvhe...@2ndquadrant.com 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
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 make sure.
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 not
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 as
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
11 matches
Mail list logo