On 9 Srp, 19:38, st...@enterprisedb.com (Gregory Stark) wrote:
> <meg...@gmail.com> writes:
> > ALTER TABLE name RENAME TO new_name;
> > ALTER TABLE new_name
> > =A0 RENAME COLUMN x TO y;
>
> ...
> > I think the issue might be reproducible by creating table with a lot
> > of rows, setting high work_mem and issuing the commands, but I did not
> > try to reproduce it this way.
>
> The commands you described should take the same length of time regardless=
of
> the size of table and the memory settings are not relevant. I suspect you=
're
> actually running some different commands?
>
> --
> =A0 Gregory Stark
> =A0 EnterpriseDB =A0 =A0 =A0 =A0 =A0http://www.enterprisedb.com
> =A0 Ask me about EnterpriseDB's On-Demand Production Tuning
>
> --
> Sent via pgsql-bugs mailing list (pgsql-b...@postgresql.org)
> To make changes to your subscription:http://www.postgresql.org/mailpref/p=
gsql-bugs
-- This script will migrate shema from the version 1.1.18 to the
version 1.2.0
-- (i.e. Gardeners integration)
This is what I actually run:
SET search_path =3D public, isn, pg_catalog;
SET maintenance_work_mem =3D 256000;
SET work_mem =3D 256000;
VACUUM FULL ANALYZE;
REINDEX DATABASE shakes;
BEGIN;
ALTER TABLE btbooks
RENAME TO exbooks;
-- following command returns the error
ALTER TABLE exbooks
RENAME COLUMN bt_price TO list_price;
-- many more other commands ....
COMMIT;