Re: Vacuum, Freeze and Analyze: the big picture

From: Greg Stark <stark(at)mit(dot)edu>
To: Josh Berkus <josh(at)agliodbs(dot)com>
Cc: PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Vacuum, Freeze and Analyze: the big picture
Date: 2013-06-05 14:40:11
Message-ID: CAM-w4HPkna59h_8fp5Y03e1-A-csRJuUOtSeMLWQmmt7wJqFtg@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Thu, May 30, 2013 at 7:48 PM, Josh Berkus <josh(at)agliodbs(dot)com> wrote:
> The big, big picture is this:
>
> 90% of our users need to think about VACUUM/ANALYZE
> at least 10% of the time
> and 10% of our users need to think about it
> almost 90% of the time.
>
> That's considerably better than was the case 5 years ago, when vacuum
> management was a daily or weekly responsibility for nearly 100% of our
> users,

Fwiw I think this is not the right picture. I think the current
situation an accurate description of the way things are and have
always been.

It's an arms race. We've raised the bar of how large and busy your
database has to be before vacuum becomes a pain and users scale their
databases up. As long as we stay one step ahead of the users 90% of
users won't have to think about vacuum/analyze much. There will always
be outliers.

When the visibility map went in the argument was that wraparound was
so rare that it wasn't worth doubling the size of the visibility map
to have a second bit. If the table gets even a low amount of traffic
nearly all blocks will need to be frozen anyways by that time. To do
something like the visibility map for freezing we would need something
like a map that stores the high 8 bits of the oldest unfrozen xid in
the block. That be a lot more complex and take a lot more space.

--
greg

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Hannu Krosing 2013-06-05 14:46:11 Re: MVCC catalog access
Previous Message Greg Stark 2013-06-05 14:28:09 Re: MVCC catalog access