From: Scott Carey <scott@richrelevance.com>
To: Stephen Frost <sfrost@snowman.net>,
 Scott Marlowe <scott.marlowe@gmail.com>
CC: Robert Schnabel <schnabelr@missouri.edu>, "david@lang.hm" <david@lang.hm>,
	pgsql-performance <pgsql-performance@postgresql.org>
Date: Fri, 28 Jan 2011 09:50:47 -0800
Subject: Re: How to best use 32 15k.7 300GB drives?
Thread-Topic: [PERFORM] How to best use 32 15k.7 300GB drives?
Thread-Index: Acu/E55xmOXgBYmFRRiKpvAQ/NAQlA==
Message-ID: <C9684183.1E40B%scott@richrelevance.com>
In-Reply-To: <20110128172810.GE30352@tamriel.snowman.net>
Accept-Language: en-US
Content-Language: en-US
user-agent: Microsoft-MacOutlook/14.2.0.101115
acceptlanguage: en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0


On 1/28/11 9:28 AM, "Stephen Frost" <sfrost@snowman.net> wrote:

>* Scott Marlowe (scott.marlowe@gmail.com) wrote:
>> There's nothing wrong with whole table updates as part of an import
>> process, you just have to know to "clean up" after you're done, and
>> regular vacuum can't fix this issue, only vacuum full or reindex or
>> cluster.
>
>Just to share my experiences- I've found that creating a new table and
>inserting into it is actually faster than doing full-table updates, if
>that's an option for you.

I wonder if postgres could automatically optimize that, if it thought that
it was going to update more than X% of a table, and HOT was not going to
help, then just create a new table file for XID's =3D or higher than the on=
e
making the change, and leave the old one for old XIDs, then regular VACUUM
could toss out the old one if no more transactions could see it.


>
>    Thanks,
>
>        Stephen