On Wed, Jan 26, 2022 at 6:46 PM Greg Stark wrote:
> One thing I've been wanting to do something about is I think
> autovacuum needs to be a little cleverer about when *not* to vacuum a
> table because it won't do any good.
I agree.
> I was thinking of just putting a check in before kicking off
On Wed, Jan 26, 2022 at 6:56 PM Greg Stark wrote:
>
> On Wed, 26 Jan 2022 at 18:46, Greg Stark wrote:
> >
> > On Thu, 20 Jan 2022 at 14:31, Robert Haas wrote:
> > >
> > > In my view, previous efforts in this area have been too simplistic.
> > >
> >
> > One thing I've been wanting to do
On Wed, 26 Jan 2022 at 18:46, Greg Stark wrote:
>
> On Thu, 20 Jan 2022 at 14:31, Robert Haas wrote:
> >
> > In my view, previous efforts in this area have been too simplistic.
> >
>
> One thing I've been wanting to do something about is I think
> autovacuum needs to be a little cleverer about
On Wed, Jan 26, 2022 at 3:46 PM Greg Stark wrote:
> One thing I've been wanting to do something about is I think
> autovacuum needs to be a little cleverer about when *not* to vacuum a
> table because it won't do any good.
There was a thread about this exact thing not too long ago:
On Thu, 20 Jan 2022 at 14:31, Robert Haas wrote:
>
> In my view, previous efforts in this area have been too simplistic.
>
One thing I've been wanting to do something about is I think
autovacuum needs to be a little cleverer about when *not* to vacuum a
table because it won't do any good.
I've
> On Wed, Jan 26, 2022 at 10:55 AM Robert Haas wrote:
> On Tue, Jan 25, 2022 at 3:32 PM Peter Geoghegan wrote:
> > For example, a
> > page that has 5 dead heap-only tuples is vastly different to a similar
> > page that has 5 LP_DEAD items instead -- and yet our current approach
> > makes no
On Tue, Jan 25, 2022 at 3:34 PM John Naylor
wrote:
> I was thinking along the same lines as Dilip: If the anti-wraparound
> risk is really far in the future, there might not be much eligible
> freezing work to do. Dead tuples can be removed as soon as visibility
> rules allow it. With a separate
On Tue, Jan 25, 2022 at 3:32 PM Peter Geoghegan wrote:
> For example, a
> page that has 5 dead heap-only tuples is vastly different to a similar
> page that has 5 LP_DEAD items instead -- and yet our current approach
> makes no distinction. Chances are very high that if the only dead
> tuples are
On Tue, Jan 25, 2022 at 2:30 PM Robert Haas wrote:
>
> On Mon, Jan 24, 2022 at 11:14 PM Dilip Kumar wrote:
> > I think we need to make different priority
> > queues based on different factors, for example 1 queue for wraparound
> > risk and another for bloat risk.
>
> I don't see why we want
On Tue, Jan 25, 2022 at 11:30 AM Robert Haas wrote:
> But your broader point that we need to consider how much bloat
> represents a problem is a really good one. In the past, one rule that
> I've thought about is: if we're vacuuming a table and we're not going
> to finish before it needs to be
On Mon, Jan 24, 2022 at 11:14 PM Dilip Kumar wrote:
> I think we need some more parameters to compare bloat vs wraparound.
> I mean in one of your examples in the 2nd paragraph we can say that
> the need-to-start of table A is earlier than table B so it's kind of
> simple. But when it comes to
On Fri, Jan 21, 2022 at 12:54 AM Robert Haas wrote:
> So at a high level, I think that what we ought to do is, first, for
> each table, estimate the time at which we think something bad will
> occur. There are several bad events: too much bloat, XID wraparound,
> MXID wraparound. We need to
On Thu, Jan 20, 2022 at 4:43 PM Robert Haas wrote:
> > Since we now have the failsafe, the scheduling algorithm can afford to
> > not give too much special attention to table age until we're maybe
> > over the 1 billion age mark -- or even 1.5 billion+. But once the
> > scheduling stuff starts to
On Thu, Jan 20, 2022 at 6:54 PM Peter Geoghegan wrote:
> I agree that it doesn't follow that table A should be more of a
> priority than table B, either because it has a greater age, or because
> its age happens to exceed some actually-arbitrary threshold. But I
> will point out that my ongoing
On Thu, Jan 20, 2022 at 11:24 AM Robert Haas wrote:
> In my view, previous efforts in this area have been too simplistic.
> For example, it's been proposed that a table that is perceived to be
> in any kind of wraparound danger ought to get top priority, but I find
> that implausible.
I agree
autovacuum, as it exists today, has some reasonable - though imperfect
- heuristics for deciding which tables need to be vacuumed or
analyzed. However, it has nothing to help it decide which tables need
to be vacuumed or analyzed first. As a result, when it's configured
aggressively enough, and
16 matches
Mail list logo
