Re: [HACKERS] BRIN index and aborted transaction

2015-07-24 Thread Simon Riggs
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

Re: [HACKERS] BRIN index and aborted transaction

2015-07-23 Thread Tatsuo Ishii
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.

Re: [HACKERS] BRIN index and aborted transaction

2015-07-23 Thread Alvaro Herrera
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

Re: [HACKERS] BRIN index and aborted transaction

2015-07-23 Thread Alvaro Herrera
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

Re: [HACKERS] BRIN index and aborted transaction

2015-07-23 Thread Josh Berkus
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

Re: [HACKERS] BRIN index and aborted transaction

2015-07-23 Thread Robert Haas
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

Re: [HACKERS] BRIN index and aborted transaction

2015-07-21 Thread Robert Haas
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

Re: [HACKERS] BRIN index and aborted transaction

2015-07-19 Thread Alvaro Herrera
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.

Re: [HACKERS] BRIN index and aborted transaction

2015-07-18 Thread Alvaro Herrera
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

Re: [HACKERS] BRIN index and aborted transaction

2015-07-18 Thread Tatsuo Ishii
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

[HACKERS] BRIN index and aborted transaction

2015-07-17 Thread Tatsuo Ishii
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