Re: CLUSTER FREEZE

From: Craig Ringer <craig(at)2ndquadrant(dot)com>
To: Josh Berkus <josh(at)agliodbs(dot)com>
Cc: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Robert Haas <robertmhaas(at)gmail(dot)com>, Amit Kapila <amit(dot)kapila16(at)gmail(dot)com>, Thomas Munro <munro(at)ip9(dot)org>, "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: CLUSTER FREEZE
Date: 2013-10-28 01:51:00
Message-ID: 526DC304.90309@2ndquadrant.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On 10/26/2013 01:20 AM, Josh Berkus wrote:
> On 10/24/2013 07:19 PM, Tom Lane wrote:
>> In any case, it's very far from obvious to me that CLUSTER ought
>> to throw away information by default, which is what you're proposing.
>
> The problem here is that you're thinking of the 1/10 of 1% of our users
> who have a serious PostgreSQL failure and post something on the lists
> for help, for which XID forensic information is useful. As opposed to
> the 99.9% of our users for whom deferred freezing is a performance
> burden. While I realize that the 0.1% of users are more likely to have
> contact with you, personally, it's still bad policy for the project.

Strong +1 from me. Doing the performant, sensible, low-admin thing by
default is really important if you don't want a database that requires a
two year training course and a professional DBA to use. Some DB vendors
make that part of their business model, but personally at least that's
certainly not the direction I'd like to see Pg go in.

Autovacuum wrap-around prevention already gets rid of this info, it's
not like it's kept forever anyway.

Anything that makes the mechanics of bloat and vacuum less visible is a
big win as far as I'm concerned.

--
Craig Ringer http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Noah Misch 2013-10-28 03:34:47 Re: dsm use of uint64
Previous Message Marcin Mańk 2013-10-27 20:43:54 Re: high-dimensional knn-GIST tests (was Re: Cube extension kNN support)