Re: [HACKERS] Summary of plans to avoid the annoyance of Freezing

On Wed, Sep 9, 2015 at 6:03 AM, Greg Stark wrote: > On Sun, Sep 6, 2015 at 1:25 PM, Andres Freund wrote: > > My vote is that we should try to get freeze maps into 9.6 - that seems > > more realistic given that we have a patch right now. Yes, it might end > > up being superflous churn, but it's r

Re: [HACKERS] Summary of plans to avoid the annoyance of Freezing

On Wed, Sep 9, 2015 at 10:03 PM, Greg Stark wrote: > On Sun, Sep 6, 2015 at 1:25 PM, Andres Freund wrote: >> My vote is that we should try to get freeze maps into 9.6 - that seems >> more realistic given that we have a patch right now. Yes, it might end >> up being superflous churn, but it's rath

Re: [HACKERS] Summary of plans to avoid the annoyance of Freezing

On Sun, Sep 6, 2015 at 1:25 PM, Andres Freund wrote: > My vote is that we should try to get freeze maps into 9.6 - that seems > more realistic given that we have a patch right now. Yes, it might end > up being superflous churn, but it's rather localized. I think around > we've put off significant

Re: [HACKERS] Summary of plans to avoid the annoyance of Freezing

On Sun, Sep 6, 2015 at 8:25 AM, Andres Freund wrote: > On 2015-08-10 07:03:02 +0100, Simon Riggs wrote: >> I was previously a proponent of (2) as a practical way forwards, but my >> proposal here today is that we don't do anything further on 2) yet, and >> seek to make progress on 5) instead. >> >

Re: [HACKERS] Summary of plans to avoid the annoyance of Freezing

On 9/6/15 7:25 AM, Andres Freund wrote: On 2015-08-10 07:03:02 +0100, Simon Riggs wrote: I was previously a proponent of (2) as a practical way forwards, but my proposal here today is that we don't do anything further on 2) yet, and seek to make progress on 5) instead. If 5) fails to bring a wo

Re: [HACKERS] Summary of plans to avoid the annoyance of Freezing

On 2015-08-10 07:03:02 +0100, Simon Riggs wrote: > I was previously a proponent of (2) as a practical way forwards, but my > proposal here today is that we don't do anything further on 2) yet, and > seek to make progress on 5) instead. > > If 5) fails to bring a workable solution by the Jan 2016 C

Re: [HACKERS] Summary of plans to avoid the annoyance of Freezing

On 10 August 2015 at 19:21, Josh Berkus wrote: > Question: does regular vacuum update the visibility map in the same way > vacuum freeze does? Yes -- Simon Riggshttp://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Remote DBA, Trainin

Re: [HACKERS] Summary of plans to avoid the annoyance of Freezing

Having a freeze map would be wholly unnecessary if we don't ever need to freeze whole tables again. Freezing would still be needed on individual blocks where an old row has been updated or deleted; a freeze map would not help there either. So there is no conflict, but options 2) and 3) are complet

Re: [HACKERS] Summary of plans to avoid the annoyance of Freezing

On 08/10/2015 10:31 AM, Simon Riggs wrote: > Freezing is not a necessary pre-condition for either of those things, I > am happy to say. There is confusion here because for ( 1 ) the shrink > was performed after freezing, but when you have access to the epoch > there is no need for exhaustive freezi

Re: [HACKERS] Summary of plans to avoid the annoyance of Freezing

On 10 August 2015 at 18:02, Josh Berkus wrote: > There's a lesser version of this item which remains relevant unless we > implement (5). That is, currently the same autovacuum_vaccuum_delay > (AVVD) applies to regular autovacuums as does to anti-wraparound > autovacuums. If the user has set AV

Re: [HACKERS] Summary of plans to avoid the annoyance of Freezing

Simon, Thank you for this summary! I was losing track, myself. On 08/09/2015 11:03 PM, Simon Riggs wrote: > Freezing is painful for VLDBs and high transaction rate systems. We have > a number of proposals to improve things... > 3. Speed up autovacuums when they are triggered to avoid wraparound

Re: [HACKERS] Summary of plans to avoid the annoyance of Freezing

On 2015-08-10 11:25:37 +0300, Heikki Linnakangas wrote: > On 08/10/2015 11:17 AM, Andres Freund wrote: > >On 2015-08-10 07:26:29 +0100, Simon Riggs wrote: > >>So there is no conflict, but options 2) and 3) are completely redundant if > >>we go for 5). After investigation, I now think 5) is achievab

Re: [HACKERS] Summary of plans to avoid the annoyance of Freezing

On 08/10/2015 11:17 AM, Andres Freund wrote: On 2015-08-10 07:26:29 +0100, Simon Riggs wrote: On 10 August 2015 at 07:14, Peter Geoghegan wrote: On Sun, Aug 9, 2015 at 11:03 PM, Simon Riggs wrote: If 5) fails to bring a workable solution by the Jan 2016 CF then we commit 2) instead. Is

Re: [HACKERS] Summary of plans to avoid the annoyance of Freezing

On 2015-08-10 07:26:29 +0100, Simon Riggs wrote: > On 10 August 2015 at 07:14, Peter Geoghegan wrote: > > > On Sun, Aug 9, 2015 at 11:03 PM, Simon Riggs > > wrote: > > > If 5) fails to bring a workable solution by the Jan 2016 CF then we > > commit > > > 2) instead. > > > > Is there actually a c

Re: [HACKERS] Summary of plans to avoid the annoyance of Freezing

On 10 August 2015 at 07:14, Peter Geoghegan wrote: > On Sun, Aug 9, 2015 at 11:03 PM, Simon Riggs > wrote: > > If 5) fails to bring a workable solution by the Jan 2016 CF then we > commit > > 2) instead. > > Is there actually a conflict there? I didn't think so. > I didn't explain myself fully,

Re: [HACKERS] Summary of plans to avoid the annoyance of Freezing

On Sun, Aug 9, 2015 at 11:03 PM, Simon Riggs wrote: > If 5) fails to bring a workable solution by the Jan 2016 CF then we commit > 2) instead. Is there actually a conflict there? I didn't think so. -- Peter Geoghegan -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To ma

[HACKERS] Summary of plans to avoid the annoyance of Freezing

Freezing is painful for VLDBs and high transaction rate systems. We have a number of proposals to improve things... 1. Allow parallel cores to be used with vacuumdb (Dilip) Idea is if we have to get the job done, lets do it as fast as we can using brute force. Reasonable thinking, but there are mo