Rather than having to go to each child table and completely dropping constraints related to the table that you wanna do a truncate on, is there a quick way to just disable any conflicting constraints quickly and easily to allow me to truncate and get out without having to do a drop/add which is combursome?
-- Disable all constraints including dependencies:
ALTER TABLE dbo.TableName NOCHECK CONSTRAINT ALL;
ALTER TABLE dbo.TableNamesDependencies NOCHECK CONSTRAINT ALL;
-- Truncate tables:
TRUNCATE TABLE dbo.TableName;
TRUNCATE TABLE dbo.TableNamesDependencies ;
-- Enable all constraints:
ALTER TABLE dbo.TableNamesDependencies NOCHECK CONSTRAINT ALL;
ALTER TABLE dbo.TableName CHECK CONSTRAINT ALL;
Related
I need to alter a unique index which has already been created to set it deferrable. In postgres 9.6. Basically, i do something like:
DROP TABLE IF EXISTS test;
CREATE TABLE test (id integer);
ALTER TABLE test ADD CONSTRAINT unique_id unique(id);
ALTER TABLE test ALTER CONSTRAINT unique_id DEFERRABLE INITIALLY DEFERRED;
But i get
ERROR: constraint "unique_id" of relation "test" is not a foreign key constraint
Documentation does not seem to mention that such action cannot be performed. What am i missing?
Per the documentation:
ALTER CONSTRAINT
This form alters the attributes of a constraint that was previously created. Currently only foreign key constraints may be altered.
Instead you can:
ALTER TABLE test DROP CONSTRAINT unique_id;
ALTER TABLE test ADD CONSTRAINT unique_id unique(id) DEFERRABLE INITIALLY DEFERRED;
I'm trying to refresh some data that's referred to by other data - I want to truncate and reload the ms_automobile table, but the rm_automobile table has a foreign key to it.
It looks like the 'DISABLE TRIGGER' statements are working (run as postgres, a superuser):
mobilesurvey=# ALTER TABLE ms_automobile DISABLE TRIGGER ALL;
ALTER TABLE
mobilesurvey=# ALTER TABLE rm_automobile DISABLE TRIGGER ALL;
ALTER TABLE
But I can't then truncate the ms_automobile table:
mobilesurvey=# TRUNCATE TABLE ms_automobile;
ERROR: cannot truncate a table referenced in a foreign key constraint
DETAIL: Table "rm_automobile" references "ms_automobile".
HINT: Truncate table "rm_automobile" at the same time, or use TRUNCATE ... CASCADE.
Again, I do not want to lose the rm_automobile data; after the TRUNCATE I'm planning on doing a pg_restore that includes the missing ms_automobile data.
If possible, I'd like to disable instead of dropping the constraints - there are more of them, and maintaining disable/enable seems a lot less error-prone than maintaining drop/add.
So, how can I actually disable the foreign keys here?
Disabling triggers works as you expect on DELETE (and not on TRUNCATE).
DELETE FROM ms_automobile;
TRUNCATE is implemented in the specific way different from INSERT/UPDATE/DELETE. It doesn't use triggers but checks referential integrity once before its execution.
I have one table that has two fields. The structure is like this:
CREATE TABLE raw_links
(
value_id bigint NOT NULL,
raw_id integer NOT NULL,
CONSTRAINT raw_links_pk PRIMARY KEY (raw_id, dp_id),
CONSTRAINT raw_fk FOREIGN KEY (raw_id)
REFERENCES raw_data (raw_data_id) MATCH SIMPLE
ON UPDATE RESTRICT ON DELETE RESTRICT
)
I have to delete 5 million records from this table. For that I want to disable both constraints so that deletion will be faster. After deletion I want to create both constraints.
You can do ALTER TABLE DROP CONSTRAINT raw_links_pk and the same for raw_fk.
After you delete the records, first do a VACUUM ANALYZE raw_links (or VACUUM FULL raw_links if you want to reclaim disk space), to update the table statistics.
Then finally rebuild the constraints with ALTER TABLE ADD CONSTRAINT ....
For the example.
Schema: source, Table: finalsales, Constrait: finalsales_pkey, Column: order_id.
--Disable Primary Key
ALTER TABLE source."finalsales" DROP CONSTRAINT finalsales_pkey;
--Enable Primary Key
ALTER TABLE source."finalsales"
ADD CONSTRAINT finalsales_pkey PRIMARY KEY ( order_id );
If I script a table with a foreign key, it looks like this:
GO
ALTER TABLE [dbo].[MyTable] WITH CHECK ADD CONSTRAINT [FK_MyTable_SomeCol] FOREIGN KEY([SomeCol])
REFERENCES [dbo].[MyOtherTable] ([SomeCol])
GO
ALTER TABLE [dbo].[MyTable] CHECK CONSTRAINT [FK_MyTable_SomeCol]
GO
What is the second part for (ALTER TABLE [dbo].[MyTable] CHECK CONSTRAINT [FK_MyTable_SomeCol])?
It's an artifact of the way that the constraint is scripted - although it's unnecessary to specify these options (since they're the defaults for new constraints), the same generator can also generate NOCHECK options in exactly the same manner.
Documentation for ALTER TABLE indicates two distinct uses of CHECK/NOCHECK:
WITH CHECK | WITH NOCHECK
Specifies whether the data in the table is or is not validated against a newly added or re-enabled FOREIGN KEY or CHECK constraint. If not specified, WITH CHECK is assumed for new constraints, and WITH NOCHECK is assumed for re-enabled constraints.
And:
{ CHECK | NOCHECK } CONSTRAINT
Specifies that constraint_name is enabled or disabled.
So one option is saying "check the current contents of the table", the other is saying "Validate new data as it is added".
This is a way of implementing referential integrity for your tables.
I have a table with approx 5 million rows which has a fk constraint referencing the primary key of another table (also approx 5 million rows).
I need to delete about 75000 rows from both tables. I know that if I try doing this with the fk constraint enabled it's going to take an unacceptable amount of time.
Coming from an Oracle background my first thought was to disable the constraint, do the delete & then reenable the constraint. PostGres appears to let me disable constraint triggers if I am a super user (I'm not, but I am logging in as the user that owns/created the objects) but that doesn't seem to be quite what I want.
The other option is to drop the constraint and then reinstate it. I'm worried that rebuilding the constraint is going to take ages given the size of my tables.
Any thoughts?
edit: after Billy's encouragement I've tried doing the delete without changing any constraints and it takes in excess of 10 minutes. However, I have discovered that the table from which I'm trying to delete has a self referential foreign key ... duplicated (& non indexed).
Final update - I dropped the self referential foreign key, did my delete and added it back in. Billy's right all round but unfortunately I can't accept his comment as the answer!
Per previous comments, it should be a problem. That said, there is a command that may be what you're looking to - it'll set the constraints to deferred so they're checked on COMMIT, not on every delete. If you're doing just one big DELETE of all the rows, it won't make a difference, but if you're doing it in pieces, it will.
SET CONSTRAINTS ALL DEFERRED
is what you are looking for in that case. Note that constraints must be marked as DEFERRABLE before they can be deferred. For example:
ALTER TABLE table_name
ADD CONSTRAINT constraint_uk UNIQUE(column_1, column_2)
DEFERRABLE INITIALLY IMMEDIATE;
The constraint can then be deferred in a transaction or function as follows:
CREATE OR REPLACE FUNCTION f() RETURNS void AS
$BODY$
BEGIN
SET CONSTRAINTS ALL DEFERRED;
-- Code that temporarily violates the constraint...
-- UPDATE table_name ...
END;
$BODY$
LANGUAGE plpgsql VOLATILE
COST 100;
What worked for me was to disable one by one the TRIGGERS of those tables that are gonna be involved in the DELETE operation.
ALTER TABLE reference DISABLE TRIGGER ALL;
DELETE FROM reference WHERE refered_id > 1;
ALTER TABLE reference ENABLE TRIGGER ALL;
Solution is working in version 9.3.16. In my case time went from 45 minutes to 14 seconds executing DELETE operations.
As stated in the comments section by #amphetamachine, you will need to have admin privileges to the tables to perform this task.
If you try DISABLE TRIGGER ALL and get an error like permission denied: "RI_ConstraintTrigger_a_16428" is a system trigger (I got this on Amazon RDS), try this:
set session_replication_role to replica;
If this succeeds, all triggers that underlie table constraints will be disabled. Now it's up to you to make sure your changes leave the DB in a consistent state!
Then when you are done, reenable triggers & constraints for your session with:
set session_replication_role to default;
(This answer assumes your intent is to delete all of the rows of these tables, not just a selection.)
I also had to do this, but as part of a test suite. I found the answer, suggested elsewhere on SO. Use TRUNCATE TABLE as follows:
TRUNCATE TABLE <list-of-table-names> [RESTART IDENTITY] [CASCADE];
The following quickly deletes all rows from tables table1, table2, and table3, provided that there are no references to rows of these tables from tables not listed:
TRUNCATE TABLE table1, table2, table3;
As long as references are between the tables listed, PostgreSQL will delete all the rows without concern for referential integrity. If a table other than those listed references a row of one of these tables, the query will fail.
However, you can qualify the query so that it also truncates all tables with references to the listed tables (although I have not tried this):
TRUNCATE TABLE table1, table2, table3 CASCADE;
By default, the sequences of these tables do not restart numbering. New rows will continue with the next number of the sequence. To restart sequence numbering:
TRUNCATE TABLE table1, table2, table3 RESTART IDENTITY;
My PostgreSQL is 9.6.8.
set session_replication_role to replica;
work for me but I need permission.
I login psql with super user.
sudo -u postgres psql
Then connect to my database
\c myDB
And run:
set session_replication_role to replica;
Now I can delete from table with constraint.
Disable all table constraints
ALTER TABLE TableName NOCHECK CONSTRAINT ConstraintName
-- Enable all table constraints
ALTER TABLE TableName CHECK CONSTRAINT ConstraintName