From: | Mark Kirkwood <mark(dot)kirkwood(at)catalyst(dot)net(dot)nz> |
---|---|
To: | pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: Pg_upgrade performance |
Date: | 2010-09-21 05:44:47 |
Message-ID: | 4C98464F.7020406@catalyst.net.nz |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On 21/09/10 16:14, Mark Kirkwood wrote:
> I've been having a look at this guy, trying to get a handle on how
> much down time it will save.
>
> As a quick check, I tried upgrading a cluster with a 1 non default db
> containing a scale 100 pgbench schema:
>
> - pg_upgrade : 57 s
> - pgdump/pg_restore : 154 s
>
> So, a reasonable saving all up - but I guess still a sizable chunk of
> downtime in the case of a big database to copy the user relation files.
>
> I notice there is a "link" option that would be quicker I guess -
> would it make sense to have a "move" option too? (perhaps with
> pg_upgrade writing an "un-move" script to move them back just in case).
Replying to this - looking more carefully at what the --link option
does, it is clear that this is in fact covered. Sorry for the (my)
confusion. For completeness, with this option the upgrade is
substantially faster:
- pg_upgrade (link): 12 s
regards
Mark
From | Date | Subject | |
---|---|---|---|
Next Message | Heikki Linnakangas | 2010-09-21 05:59:53 | Re: Any reason why the default_with_oids GUC is still there? |
Previous Message | Tom Lane | 2010-09-21 05:06:51 | Re: .gitignore files, take two |