Vacuum, Freeze and Analyze: the big picture

From: Jeff Janes <jeff(dot)janes(at)gmail(dot)com>
To: Robert Haas <robertmhaas(at)gmail(dot)com>
Cc: Simon Riggs <simon(at)2ndquadrant(dot)com>, Josh Berkus <josh(at)agliodbs(dot)com>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Vacuum, Freeze and Analyze: the big picture
Date: 2013-06-02 18:44:04
Message-ID: CAMkU=1xCroGg_poyjO307XHZhzPVicGSeuH_CFKZkC+n-vk4pQ@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Saturday, June 1, 2013, Robert Haas wrote:

>
> I agree with all that. I don't have any data either, but I agree that
> AFAICT it seems to mostly be a problem for large (terabyte-scale)
> databases, or ones that are dreadfully short of I/O bandwidth. AWS,
> I'm looking at you.
>
> It would be interesting to make a list of what other issues people
> have seen using PostgreSQL on very large data sets. Complaints I've
> heard include:
>
> 1. Inexplicable failure of the planner to use indexes on very large
> tables, preferring an obviously-stupid sequential scan. This might be
> fixed by the latest index-size fudge factor work.
>
> 2. Lack of concurrent DDL.
>
> On VACUUM and ANALYZE specifically, I'd have to say that the most
> common problems I encounter are (a) anti-wraparound vacuums kicking in
> at inconvenient times and eating up too many resources and (b) users
> making ridiculous settings changes to avoid the problems caused by
> anti-wraparound vacuums kicking in at inconvenient times and eating up
> too many resources.

Do we know why anti-wraparound uses so many resources in the first place?
The default settings seem to be quite conservative to me, even for a
system that has only a single 5400 rpm hdd (and even more so for any real
production system that would be used for a many-GB database).

I wonder if there is something simple but currently unknown going on which
is causing it to damage performance out of all proportion to the resources
it ought to be using.

Cheers,

Jeff

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Dimitri Fontaine 2013-06-02 20:10:13 Re: pg_dump with postgis extension dumps rules separately
Previous Message Fujii Masao 2013-06-02 17:14:38 Re: [PATCH] pg_isready (was: [WIP] pg_ping utility)