Stephen Frost wrote:
> * Alvaro Herrera (alvhe...@2ndquadrant.com) wrote:
> > I am rather surprised that nobody has reported this problem before. I
> > am now of the mind that this is clearly a bug that should be fixed all
> > the way back.
>
> I'm coming around to that also, however, should we
* Alvaro Herrera (alvhe...@2ndquadrant.com) wrote:
> Alvaro Herrera wrote:
> > Basically, if you are on 9.3.5 or earlier any per-table options for
> > autovacuum cost delay will misbehave (meaning: any such table will be
> > processed with settings flattened according to balancing of the standard
>
Alvaro Herrera wrote:
> Basically, if you are on 9.3.5 or earlier any per-table options for
> autovacuum cost delay will misbehave (meaning: any such table will be
> processed with settings flattened according to balancing of the standard
> options, _not_ the configured ones). If you are on 9.3.6
Stephen Frost wrote:
> * Robert Haas (robertmh...@gmail.com) wrote:
> > I agree with both of those arguments. I have run into very few
> > customers who have used the autovacuum settings to customize behavior
> > for particular tables, and anyone who hasn't should see no change
> > (right?), so m
* Robert Haas (robertmh...@gmail.com) wrote:
> On Thu, Oct 2, 2014 at 9:54 AM, Alvaro Herrera
> wrote:
> > Alvaro Herrera wrote:
> >> So in essence what we're going to do is that the balance mechanism
> >> considers only tables that don't have per-table configuration options;
> >> for those that
On Thu, Oct 2, 2014 at 9:54 AM, Alvaro Herrera wrote:
> Alvaro Herrera wrote:
>> So in essence what we're going to do is that the balance mechanism
>> considers only tables that don't have per-table configuration options;
>> for those that do, we will use the values configured there without any
>>
On Tue, Sep 30, 2014 at 6:16 PM, Alvaro Herrera
wrote:
> Robert Haas wrote:
>> I favor option (a). There's something to be said for your proposal
>> in terms of logical consistency with what we have now, but to be
>> honest I'm not sure it's the behavior anyone wants (I would welcome
>> more fee
Robert Haas wrote:
> I favor option (a). There's something to be said for your proposal
> in terms of logical consistency with what we have now, but to be
> honest I'm not sure it's the behavior anyone wants (I would welcome
> more feedback on what people actually want). I think we should view
On 8/28/14, 12:18 PM, Robert Haas wrote:
At least in situations that I've encountered, it's typical to be able
to determine the frequency with which a given table needs to be
vacuumed to avoid runaway bloat, and from that you can work backwards
to figure out how fast you must process it in MB/s
On Thu, Aug 28, 2014 at 11:06 PM, Alvaro Herrera
wrote:
>
> Robert Haas wrote:
>
> > Now, in the case where you are setting an overall limit, there is at
> > least an argument to be made that you can determine the overall rate
> > of autovacuum-induced I/O activity that the system can tolerate, an
On Tue, Aug 26, 2014 at 9:49 PM, Alvaro Herrera
wrote:
>
> So my proposal is a bit more complicated. First we introduce the notion
> of a single number, to enable sorting and computations: the "delay
> equivalent", which is the cost_limit divided by cost_delay. The highest
> the value is for any
Mark Kirkwood wrote:
> On 29/08/14 08:56, Alvaro Herrera wrote:
> >Robert Haas wrote:
> >
> >>I agree that you might not like that. But you might not like having
> >>the table vacuumed slower than the configured rate, either. My
> >>impression is that the time between vacuums isn't really all tha
On 29/08/14 08:56, Alvaro Herrera wrote:
Robert Haas wrote:
I agree that you might not like that. But you might not like having
the table vacuumed slower than the configured rate, either. My
impression is that the time between vacuums isn't really all that
negotiable for some people. I had o
On Thu, Aug 28, 2014 at 4:56 PM, Alvaro Herrera
wrote:
> Robert Haas wrote:
>> I agree that you might not like that. But you might not like having
>> the table vacuumed slower than the configured rate, either. My
>> impression is that the time between vacuums isn't really all that
>> negotiable
Robert Haas wrote:
> I agree that you might not like that. But you might not like having
> the table vacuumed slower than the configured rate, either. My
> impression is that the time between vacuums isn't really all that
> negotiable for some people. I had one customer who had horrible bloat
>
On Thu, Aug 28, 2014 at 1:36 PM, Alvaro Herrera
wrote:
> Robert Haas wrote:
>> Now, in the case where you are setting an overall limit, there is at
>> least an argument to be made that you can determine the overall rate
>> of autovacuum-induced I/O activity that the system can tolerate, and
>> set
Robert Haas wrote:
> Now, in the case where you are setting an overall limit, there is at
> least an argument to be made that you can determine the overall rate
> of autovacuum-induced I/O activity that the system can tolerate, and
> set your limits to stay within that budget, and then let the sys
On Tue, Aug 26, 2014 at 12:19 PM, Alvaro Herrera
wrote:
>> >On Mon, May 5, 2014 at 11:57 AM, Mark Kirkwood
>> > wrote:
>> >I could think of 2 ways to change this:
>> >
>> >a. if user has specified cost_limit value for table, then it just uses it
>> > rather than rebalancing based on value of s
On 27/08/14 10:27, Alvaro Herrera wrote:
Alvaro Herrera wrote:
So my proposal is a bit more complicated. First we introduce the notion
of a single number, to enable sorting and computations: the "delay
equivalent", which is the cost_limit divided by cost_delay.
Here's a patch that implements
On Wed, Aug 27, 2014 at 8:27 AM, Alvaro Herrera
wrote:
> Alvaro Herrera wrote:
>
>> So my proposal is a bit more complicated. First we introduce the notion
>> of a single number, to enable sorting and computations: the "delay
>> equivalent", which is the cost_limit divided by cost_delay.
>
> Here
On 27/08/14 10:27, Alvaro Herrera wrote:
Alvaro Herrera wrote:
So my proposal is a bit more complicated. First we introduce the notion
of a single number, to enable sorting and computations: the "delay
equivalent", which is the cost_limit divided by cost_delay.
Here's a patch that implements
Mark Kirkwood wrote:
> On 06/05/14 16:28, Amit Kapila wrote:
> >On Mon, May 5, 2014 at 11:57 AM, Mark Kirkwood
> > wrote:
> >I could think of 2 ways to change this:
> >
> >a. if user has specified cost_limit value for table, then it just uses it
> > rather than rebalancing based on value of s
On 06/05/14 16:28, Amit Kapila wrote:
On Mon, May 5, 2014 at 11:57 AM, Mark Kirkwood
wrote:
On 05/05/14 15:22, Amit Kapila wrote:
Right, but have a look at the 1st message in this thread - the current
behavior (and to a large extent the above condition) means that setting
cost limits per table
On Mon, May 5, 2014 at 11:57 AM, Mark Kirkwood
wrote:
> On 05/05/14 15:22, Amit Kapila wrote:
> Right, but have a look at the 1st message in this thread - the current
> behavior (and to a large extent the above condition) means that setting
> cost limits per table does not work in any remotely int
On 05/05/14 15:22, Amit Kapila wrote:
Here what I could understand is that sum of cost_limit for all
autovacuum workers should never exceed the value of
autovacuum_vacuum_cost_limit which seems to be always the
case in current code but same is not true for proposed patch.
Right, but have a lo
On Mon, May 5, 2014 at 6:35 AM, Haribabu Kommi wrote:
> On Mon, May 5, 2014 at 1:09 AM, Amit Kapila wrote:
>> On Mon, Feb 17, 2014 at 7:38 AM, Haribabu Kommi
>> wrote:
>>> I modified the "autovac_balance_cost" function to balance the costs using
>>> the number of running workers, instead
>>> of
On Mon, May 5, 2014 at 1:09 AM, Amit Kapila wrote:
> On Mon, Feb 17, 2014 at 7:38 AM, Haribabu Kommi
> wrote:
>> I modified the "autovac_balance_cost" function to balance the costs using
>> the number of running workers, instead
>> of default vacuum cost parameters.
>>
>> Lets assume there are 4
On Mon, Feb 17, 2014 at 7:38 AM, Haribabu Kommi
wrote:
> I modified the "autovac_balance_cost" function to balance the costs using
> the number of running workers, instead
> of default vacuum cost parameters.
>
> Lets assume there are 4 workers running currently with default cost values
> of limit
Haribabu Kommi wrote:
> I modified the "autovac_balance_cost" function to balance the costs using
> the number of running workers, instead
> of default vacuum cost parameters.
Just as a heads-up, this patch wasn't part of the commitfest, but I
intend to review it and possibly commit for 9.4. Not
On Feb 15, 2014 9:19 AM, "Alvaro Herrera" wrote:
>
> Haribabu Kommi escribió:
>
> > I changed the balance cost calculations a little bit to give priority to
> > the user provided per table autovacuum parameters.
> > If any user specified per table vacuum parameters exists and those are
> > differe
Haribabu Kommi escribió:
> I changed the balance cost calculations a little bit to give priority to
> the user provided per table autovacuum parameters.
> If any user specified per table vacuum parameters exists and those are
> different with guc vacuum parameters then the
> balance cost calculati
I hadn't noticed this thread. I will give this a look. Thanks for
providing a patch.
--
Álvaro Herrerahttp://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to
32 matches
Mail list logo
