On 9 Srp, 19:38, [EMAIL PROTECTED] (Gregory Stark) wrote: > <[EMAIL PROTECTED]> 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 ([EMAIL PROTECTED]) > 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
