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
>
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
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
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
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
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
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
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
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
>>
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
>
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
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
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
>
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
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
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
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
17 matches
Mail list logo