Re: [HACKERS] Avoiding pin scan during btree vacuum

2016-11-17 Thread Alvaro Herrera
Alvaro Herrera wrote: > I am ready now to backpatch this to 9.4 and 9.5; here are the patches. > They are pretty similar, but some adjustments were needed due to XLog > format changes in 9.5. (I kept most of Simon's original commit > message.) Finally done. -- Álvaro Herrera

Re: [HACKERS] Avoiding pin scan during btree vacuum

2016-11-16 Thread Alvaro Herrera
I am ready now to backpatch this to 9.4 and 9.5; here are the patches. They are pretty similar, but some adjustments were needed due to XLog format changes in 9.5. (I kept most of Simon's original commit message.) This patch has survived in master for a long time, and in released 9.6 for a

Re: [HACKERS] Avoiding pin scan during btree vacuum

2016-10-23 Thread Alvaro Herrera
Robert Haas wrote: > On Wed, Oct 19, 2016 at 6:30 PM, Alvaro Herrera > wrote: > > Robert Haas wrote: > >> On Mon, Jan 4, 2016 at 10:30 AM, Tom Lane wrote: > >> >> This seems like a might subtle thing to backpatch. If we really want to > >> >> go

Re: [HACKERS] Avoiding pin scan during btree vacuum

2016-10-20 Thread Robert Haas
On Wed, Oct 19, 2016 at 6:30 PM, Alvaro Herrera wrote: > Robert Haas wrote: >> On Mon, Jan 4, 2016 at 10:30 AM, Tom Lane wrote: >> >> This seems like a might subtle thing to backpatch. If we really want to >> >> go there, ISTM that the relevant code

Re: [HACKERS] Avoiding pin scan during btree vacuum

2016-10-19 Thread Amit Kapila
On Thu, Oct 20, 2016 at 4:00 AM, Alvaro Herrera wrote: > Robert Haas wrote: >> On Mon, Jan 4, 2016 at 10:30 AM, Tom Lane wrote: >> >> This seems like a might subtle thing to backpatch. If we really want to >> >> go there, ISTM that the relevant code

Re: [HACKERS] Avoiding pin scan during btree vacuum

2016-10-19 Thread Alvaro Herrera
Robert Haas wrote: > On Mon, Jan 4, 2016 at 10:30 AM, Tom Lane wrote: > >> This seems like a might subtle thing to backpatch. If we really want to > >> go there, ISTM that the relevant code should stew in an unreleased > >> branch for a while, before being backpatched. > > > >

Re: [HACKERS] Avoiding pin scan during btree vacuum

2016-01-04 Thread Andres Freund
On 2016-01-03 15:40:01 +, Simon Riggs wrote: > I'm happy with this being a simple patch now, not least because I would > like to backpatch this to 9.4 where catalog scans became MVCC. > > A backpatch is warranted because it is a severe performance issue with > replication and we can fix that

Re: [HACKERS] Avoiding pin scan during btree vacuum

2016-01-04 Thread Tom Lane
Andres Freund writes: > On 2016-01-03 15:40:01 +, Simon Riggs wrote: >> I'm happy with this being a simple patch now, not least because I would >> like to backpatch this to 9.4 where catalog scans became MVCC. >> >> A backpatch is warranted because it is a severe

Re: [HACKERS] Avoiding pin scan during btree vacuum

2016-01-04 Thread Robert Haas
On Mon, Jan 4, 2016 at 10:30 AM, Tom Lane wrote: >> This seems like a might subtle thing to backpatch. If we really want to >> go there, ISTM that the relevant code should stew in an unreleased >> branch for a while, before being backpatched. > > I'm definitely -1 on

Re: [HACKERS] Avoiding pin scan during btree vacuum

2016-01-03 Thread Simon Riggs
On 21 December 2015 at 21:28, Alvaro Herrera wrote: > Simon Riggs wrote: > > During VACUUM of btrees, we need to pin all pages, even those where > tuples > > are not removed, which I am calling here the "pin scan". This is > especially > > a problem during redo, where

Re: [HACKERS] Avoiding pin scan during btree vacuum

2016-01-03 Thread Simon Riggs
On 21 December 2015 at 21:36, Tom Lane wrote: > Alvaro Herrera writes: > > I think the new comment that talks about Toast Index should explain > > *why* we can skip the pinning in all cases except that one, instead of > > just saying we can do it. >

Re: [HACKERS] Avoiding pin scan during btree vacuum

2015-12-21 Thread Alvaro Herrera
Simon Riggs wrote: > During VACUUM of btrees, we need to pin all pages, even those where tuples > are not removed, which I am calling here the "pin scan". This is especially > a problem during redo, where removing one tuple from a 100GB btree can take > a minute or more. That causes replication

Re: [HACKERS] Avoiding pin scan during btree vacuum

2015-12-21 Thread Tom Lane
Alvaro Herrera writes: > I think the new comment that talks about Toast Index should explain > *why* we can skip the pinning in all cases except that one, instead of > just saying we can do it. I've not looked at that code in a long while, but my recollection is that

[HACKERS] Avoiding pin scan during btree vacuum

2015-12-21 Thread Simon Riggs
During VACUUM of btrees, we need to pin all pages, even those where tuples are not removed, which I am calling here the "pin scan". This is especially a problem during redo, where removing one tuple from a 100GB btree can take a minute or more. That causes replication lags. Bad Thing. Previously,