Re: [HACKERS] Improving replay of XLOG_BTREE_VACUUM records

2016-03-25 Thread Vladimir Borodin
> 25 марта 2016 г., в 19:11, David Steele написал(а): > > Hi Vladimir, > > On 3/14/16 2:15 PM, Vladimir Borodin wrote: > >> JFYI, I’m preparing the stand to reproduce the initial problem and I >> hope to finish testing this week. > > Do you know when you'll have the results from the testing y

Re: [HACKERS] Improving replay of XLOG_BTREE_VACUUM records

2016-03-25 Thread David Steele
Hi Vladimir, On 3/14/16 2:15 PM, Vladimir Borodin wrote: JFYI, I’m preparing the stand to reproduce the initial problem and I hope to finish testing this week. Do you know when you'll have the results from the testing you were going to do? It seems this patch is currently waiting on that to

Re: [HACKERS] Improving replay of XLOG_BTREE_VACUUM records

2016-03-14 Thread Vladimir Borodin
> 10 марта 2016 г., в 14:38, Simon Riggs написал(а): > > On 10 March 2016 at 09:22, Michael Paquier > wrote: > On Thu, Mar 10, 2016 at 10:00 AM, Vladimir Borodin > wrote: > > Let’s do immediately after you will send a new version of yo

Re: [HACKERS] Improving replay of XLOG_BTREE_VACUUM records

2016-03-11 Thread Simon Riggs
On 10 March 2016 at 11:38, Simon Riggs wrote: > On 10 March 2016 at 09:22, Michael Paquier > wrote: > >> On Thu, Mar 10, 2016 at 10:00 AM, Vladimir Borodin >> wrote: >> > Let’s do immediately after you will send a new version of your patch? Or >> > even better after testing your patch? Don’t ge

Re: [HACKERS] Improving replay of XLOG_BTREE_VACUUM records

2016-03-10 Thread Simon Riggs
On 10 March 2016 at 09:22, Michael Paquier wrote: > On Thu, Mar 10, 2016 at 10:00 AM, Vladimir Borodin > wrote: > > Let’s do immediately after you will send a new version of your patch? Or > > even better after testing your patch? Don’t get me wrong, but rejecting > my > > patch without tangible

Re: [HACKERS] Improving replay of XLOG_BTREE_VACUUM records

2016-03-10 Thread Michael Paquier
On Thu, Mar 10, 2016 at 10:00 AM, Vladimir Borodin wrote: > Let’s do immediately after you will send a new version of your patch? Or > even better after testing your patch? Don’t get me wrong, but rejecting my > patch without tangible work on your patch may lead to forgiving about the > problem be

Re: [HACKERS] Improving replay of XLOG_BTREE_VACUUM records

2016-03-10 Thread Vladimir Borodin
> 10 марта 2016 г., в 11:50, Simon Riggs написал(а): > > On 10 March 2016 at 06:27, Michael Paquier > wrote: > On Thu, Mar 10, 2016 at 1:29 AM, David Steele > wrote: > > On 1/8/16 9:34 AM, Alvaro Herrera wrote: > >> Simon Riggs wrot

Re: [HACKERS] Improving replay of XLOG_BTREE_VACUUM records

2016-03-10 Thread Simon Riggs
On 10 March 2016 at 06:27, Michael Paquier wrote: > On Thu, Mar 10, 2016 at 1:29 AM, David Steele wrote: > > On 1/8/16 9:34 AM, Alvaro Herrera wrote: > >> Simon Riggs wrote: > >>> > >>> On 8 January 2016 at 13:36, Alvaro Herrera > >>> wrote: > > I would agree except for the observatio

Re: [HACKERS] Improving replay of XLOG_BTREE_VACUUM records

2016-03-09 Thread Michael Paquier
On Thu, Mar 10, 2016 at 1:29 AM, David Steele wrote: > On 1/8/16 9:34 AM, Alvaro Herrera wrote: >> Simon Riggs wrote: >>> >>> On 8 January 2016 at 13:36, Alvaro Herrera >>> wrote: I would agree except for the observation on toast indexes. I think that's an important enough use cas

Re: [HACKERS] Improving replay of XLOG_BTREE_VACUUM records

2016-03-09 Thread David Steele
On 1/8/16 9:34 AM, Alvaro Herrera wrote: Simon Riggs wrote: On 8 January 2016 at 13:36, Alvaro Herrera wrote: I would agree except for the observation on toast indexes. I think that's an important enough use case that perhaps we should have both. The exclusion of toast indexes is something w

Re: [HACKERS] Improving replay of XLOG_BTREE_VACUUM records

2016-01-08 Thread Alvaro Herrera
Simon Riggs wrote: > On 8 January 2016 at 13:36, Alvaro Herrera wrote: > > I would agree except for the observation on toast indexes. I think > > that's an important enough use case that perhaps we should have both. > > The exclusion of toast indexes is something we can remove also, I have > re

Re: [HACKERS] Improving replay of XLOG_BTREE_VACUUM records

2016-01-08 Thread Simon Riggs
On 8 January 2016 at 13:36, Alvaro Herrera wrote: > Vladimir Borodin wrote: > > > > > 7 янв. 2016 г., в 5:26, Michael Paquier > написал(а): > > > > > > On Thu, Jan 7, 2016 at 12:20 AM, Alvaro Herrera > > > mailto:alvhe...@2ndquadrant.com>> wrote: > > > >> Would you please have a look at Simon's

Re: [HACKERS] Improving replay of XLOG_BTREE_VACUUM records

2016-01-08 Thread Alvaro Herrera
Vladimir Borodin wrote: > > > 7 янв. 2016 г., в 5:26, Michael Paquier > > написал(а): > > > > On Thu, Jan 7, 2016 at 12:20 AM, Alvaro Herrera > > mailto:alvhe...@2ndquadrant.com>> wrote: > >> Would you please have a look at Simon's patch, in particular verify > >> whether it solves the perform

Re: [HACKERS] Improving replay of XLOG_BTREE_VACUUM records

2016-01-08 Thread Vladimir Borodin
> 7 янв. 2016 г., в 5:26, Michael Paquier > написал(а): > > On Thu, Jan 7, 2016 at 12:20 AM, Alvaro Herrera > mailto:alvhe...@2ndquadrant.com>> wrote: >> Vladimir Borodin wrote: >> >>> There are situations in which vacuuming big btree index causes stuck >>> in WAL replaying on hot standby serv

Re: [HACKERS] Improving replay of XLOG_BTREE_VACUUM records

2016-01-06 Thread Michael Paquier
On Thu, Jan 7, 2016 at 12:20 AM, Alvaro Herrera wrote: > Vladimir Borodin wrote: > >> There are situations in which vacuuming big btree index causes stuck >> in WAL replaying on hot standby servers for quite a long time. I’ve >> described the problem in more details in this thread [0]. Below in >>

Re: [HACKERS] Improving replay of XLOG_BTREE_VACUUM records

2016-01-06 Thread Alvaro Herrera
Vladimir Borodin wrote: > There are situations in which vacuuming big btree index causes stuck > in WAL replaying on hot standby servers for quite a long time. I’ve > described the problem in more details in this thread [0]. Below in > that thread Kevin Grittner proposed a good way for improving b

Re: [HACKERS] Improving replay of XLOG_BTREE_VACUUM records

2015-12-16 Thread Michael Paquier
On Thu, Sep 3, 2015 at 6:10 AM, Vladimir Borodin wrote: > Patch with implementation attached. > Sorry for delay, I will link it to the current commitfest. This patch looks correct, and is doing what it claims it does. It is also not really worth refactoring the bit of code in PrefetchBuffer that d

Re: [HACKERS] Improving replay of XLOG_BTREE_VACUUM records

2015-09-02 Thread Andres Freund
On 2015-09-02 22:46:59 +0100, Greg Stark wrote: > On Sun, Jul 26, 2015 at 1:46 PM, Andres Freund wrote: > > To me it sounds like this shouldn't go through the full ReadBuffer() > > rigamarole. That code is already complex enough, and here it's really > > not needed. I think it'll be much easier to

Re: [HACKERS] Improving replay of XLOG_BTREE_VACUUM records

2015-09-02 Thread Greg Stark
On Sun, Jul 26, 2015 at 1:46 PM, Andres Freund wrote: > To me it sounds like this shouldn't go through the full ReadBuffer() > rigamarole. That code is already complex enough, and here it's really > not needed. I think it'll be much easier to review - and actually faster > in many cases to simply

Re: [HACKERS] Improving replay of XLOG_BTREE_VACUUM records

2015-09-02 Thread Vladimir Borodin
25 авг. 2015 г., в 16:03, Michael Paquier написал(а):On Sun, Jul 26, 2015 at 9:46 PM, Andres Freund wrote:On 2015-07-24 09:53:49 +0300, Heikki Linnakangas wrote:To me it sounds like this shouldn't go through the full ReadBuffer()rigamarole. That code is already complex e

Re: [HACKERS] Improving replay of XLOG_BTREE_VACUUM records

2015-08-25 Thread Michael Paquier
On Sun, Jul 26, 2015 at 9:46 PM, Andres Freund wrote: > On 2015-07-24 09:53:49 +0300, Heikki Linnakangas wrote: > To me it sounds like this shouldn't go through the full ReadBuffer() > rigamarole. That code is already complex enough, and here it's really > not needed. I think it'll be much easier t

Re: [HACKERS] Improving replay of XLOG_BTREE_VACUUM records

2015-07-26 Thread Andres Freund
On 2015-07-24 09:53:49 +0300, Heikki Linnakangas wrote: > On 05/02/2015 02:10 AM, Jim Nasby wrote: > >This looks like a good way to address this until the more significant > >work can be done. > > > >I'm not a fan of "RBM_ZERO_NO_BM_VALID"; how about RBM_ZERO_BM_INVALID? > >or BM_NOT_VALID? Or mayb

Re: [HACKERS] Improving replay of XLOG_BTREE_VACUUM records

2015-07-24 Thread Jim Nasby
On 7/24/15 1:53 AM, Heikki Linnakangas wrote: On 05/02/2015 02:10 AM, Jim Nasby wrote: This looks like a good way to address this until the more significant work can be done. I'm not a fan of "RBM_ZERO_NO_BM_VALID"; how about RBM_ZERO_BM_INVALID? or BM_NOT_VALID? Or maybe I'm just trying to imp

Re: [HACKERS] Improving replay of XLOG_BTREE_VACUUM records

2015-07-23 Thread Heikki Linnakangas
On 05/02/2015 02:10 AM, Jim Nasby wrote: This looks like a good way to address this until the more significant work can be done. I'm not a fan of "RBM_ZERO_NO_BM_VALID"; how about RBM_ZERO_BM_INVALID? or BM_NOT_VALID? Or maybe I'm just trying to impose too much English on the code; I see the log

Re: [HACKERS] Improving replay of XLOG_BTREE_VACUUM records

2015-05-03 Thread Vladimir Borodin
Hi, Jim.Thanks for review.2 мая 2015 г., в 2:10, Jim Nasby написал(а):On 5/1/15 11:19 AM, Vladimir Borodin wrote:There are situations in which vacuuming big btree index causes stuck inWAL replaying on hot standby servers for quite a long time. I’vedescribed the problem in

Re: [HACKERS] Improving replay of XLOG_BTREE_VACUUM records

2015-05-01 Thread Jim Nasby
On 5/1/15 11:19 AM, Vladimir Borodin wrote: There are situations in which vacuuming big btree index causes stuck in WAL replaying on hot standby servers for quite a long time. I’ve described the problem in more details in this thread [0]. Below in that thread Kevin Grittner proposed a good way fo