Re: [HACKERS] VACUUM's ancillary tasks

2017-01-30 Thread Alvaro Herrera
Thomas Munro wrote: > About BRIN indexes: I couldn't find an explanation of why BRIN > indexes don't automatically create new summary tuples when you insert > a new tuple in an unsummarised page range. Is it deferred until > VACUUM time in order to untangle some otherwise unresolvable >

Re: [HACKERS] VACUUM's ancillary tasks

2016-12-01 Thread Haribabu Kommi
On Wed, Oct 19, 2016 at 2:44 AM, Robert Haas wrote: > On Sun, Oct 16, 2016 at 3:35 PM, Jeff Janes wrote: > > On Fri, Oct 7, 2016 at 6:14 AM, Robert Haas > wrote: > >> On Thu, Oct 6, 2016 at 8:40 PM, Jeff Janes

Re: [HACKERS] VACUUM's ancillary tasks

2016-10-18 Thread Robert Haas
On Sun, Oct 16, 2016 at 3:35 PM, Jeff Janes wrote: > On Fri, Oct 7, 2016 at 6:14 AM, Robert Haas wrote: >> On Thu, Oct 6, 2016 at 8:40 PM, Jeff Janes wrote: >> > In commit 37484ad2aacef5ec7, you changed the way that frozen

Re: [HACKERS] VACUUM's ancillary tasks

2016-10-16 Thread Jeff Janes
On Fri, Oct 7, 2016 at 6:14 AM, Robert Haas wrote: > On Thu, Oct 6, 2016 at 8:40 PM, Jeff Janes wrote: > > In commit 37484ad2aacef5ec7, you changed the way that frozen tuples were > > represented, so that we could make freezing more aggressive

Re: [HACKERS] VACUUM's ancillary tasks

2016-10-07 Thread Robert Haas
On Thu, Oct 6, 2016 at 8:40 PM, Jeff Janes wrote: > In commit 37484ad2aacef5ec7, you changed the way that frozen tuples were > represented, so that we could make freezing more aggressive without losing > forensic evidence. But I don't think we ever did anything to actually

Re: [HACKERS] VACUUM's ancillary tasks

2016-10-07 Thread Masahiko Sawada
On Fri, Oct 7, 2016 at 6:46 AM, Robert Haas wrote: > On Thu, Oct 6, 2016 at 3:56 PM, Jeff Janes wrote: >>> Sure, I could handle each case separately, but the goal of this patch >>> (as hinted at in the Subject) is to generalize all the different tasks

Re: [HACKERS] VACUUM's ancillary tasks

2016-10-07 Thread Masahiko Sawada
On Fri, Oct 7, 2016 at 9:40 AM, Jeff Janes wrote: > On Thu, Oct 6, 2016 at 2:46 PM, Robert Haas wrote: >> >> >> > Also, I think that doing more counts which get amalgamated into the same >> > threshold, rather than introducing another parameter, is a

Re: [HACKERS] VACUUM's ancillary tasks

2016-10-06 Thread Jeff Janes
On Thu, Oct 6, 2016 at 2:46 PM, Robert Haas wrote: > > > Also, I think that doing more counts which get amalgamated into the same > > threshold, rather than introducing another parameter, is a bad thing. I > > have insert-mostly, most of the time, tables which are never

Re: [HACKERS] VACUUM's ancillary tasks

2016-10-06 Thread Robert Haas
On Thu, Oct 6, 2016 at 3:56 PM, Jeff Janes wrote: >> Sure, I could handle each case separately, but the goal of this patch >> (as hinted at in the Subject) is to generalize all the different tasks >> we've been giving to VACUUM. The only missing piece is what the first >>

Re: [HACKERS] VACUUM's ancillary tasks

2016-10-06 Thread Jeff Janes
On Sat, Oct 1, 2016 at 1:34 PM, Vik Fearing wrote: > > Sure, I could handle each case separately, but the goal of this patch > (as hinted at in the Subject) is to generalize all the different tasks > we've been giving to VACUUM. The only missing piece is what the first >

Re: [HACKERS] VACUUM's ancillary tasks

2016-10-01 Thread Thomas Munro
On Sun, Oct 2, 2016 at 9:34 AM, Vik Fearing wrote: > On 10/01/2016 09:28 AM, Thomas Munro wrote: >> On Mon, Aug 29, 2016 at 1:26 PM, Vik Fearing wrote: >>> The attached two patches scratch two itches I've been having for a >>> while. I'm attaching them

Re: [HACKERS] VACUUM's ancillary tasks

2016-10-01 Thread Vik Fearing
On 10/01/2016 09:28 AM, Thomas Munro wrote: > On Mon, Aug 29, 2016 at 1:26 PM, Vik Fearing wrote: >> The attached two patches scratch two itches I've been having for a >> while. I'm attaching them together because the second depends on the first. >> >> Both deal with the

Re: [HACKERS] VACUUM's ancillary tasks

2016-10-01 Thread Thomas Munro
On Mon, Aug 29, 2016 at 1:26 PM, Vik Fearing wrote: > The attached two patches scratch two itches I've been having for a > while. I'm attaching them together because the second depends on the first. > > Both deal with the fact that [auto]vacuum has taken on more roles than >

Re: [HACKERS] VACUUM's ancillary tasks

2016-09-26 Thread Thomas Munro
On Tue, Sep 27, 2016 at 2:33 AM, Tom Lane wrote: > Thomas Munro writes: >> I noticed that ATExecAlterColumnType does this: >> * Drop any pg_statistic entry for the column, since it's now wrong type > >> What if there is no rewrite, because

Re: [HACKERS] VACUUM's ancillary tasks

2016-09-26 Thread Tom Lane
Thomas Munro writes: > I noticed that ATExecAlterColumnType does this: > * Drop any pg_statistic entry for the column, since it's now wrong type > What if there is no rewrite, because the type is binary compatible > (ATColumnChangeRequiresRewrite returns

Re: [HACKERS] VACUUM's ancillary tasks

2016-09-25 Thread Thomas Munro
On Mon, Aug 29, 2016 at 1:26 PM, Vik Fearing wrote: > While doing this, I noticed that ALTER TABLE should also re-analyze the > table for obvious reasons, so I have that one set > "changes_since_analyze" to the number of rows rewritten as well. I noticed that

Re: [HACKERS] VACUUM's ancillary tasks

2016-08-28 Thread Andres Freund
Hi, On 2016-08-29 03:26:06 +0200, Vik Fearing wrote: > The attached two patches scratch two itches I've been having for a > while. I'm attaching them together because the second depends on the first. > > Both deal with the fact that [auto]vacuum has taken on more roles than > its original