> <meg...@gmail.com> writes:
> > ALTER TABLE name RENAME TO new_name;
> > ALTER TABLE new_name
> > 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?
>
> --
> Gregory Stark
> EnterpriseDB http://www.enterprisedb.com
> 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/pgsql-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 = public, isn, pg_catalog;
SET maintenance_work_mem = 256000;
SET work_mem = 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;
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs
No comments:
Post a Comment