Spalte zu großer Tabelle in Postgresql ohne Ausfallzeiten hinzufügen

Question

Ich habe eine sehr kleine Tabelle (ca. 1 Mil Reihen) und ich werde Einschränkungen fallen lassen und neue Spalte hinzufügen. Die Abfrage unten ist ca. 5 Minuten lang, musste zurückgesetzt werden.

BEGIN WORK; 
LOCK TABLE usertable IN SHARE MODE; 
ALTER TABLE usertable ALTER COLUMN email DROP NOT NULL; 
COMMIT WORK; 

Ein anderer Ansatz vorgeschlagen, auf den ähnlichen Fragen im Internet -

CREATE TABLE new_tbl 
(
    field1 int, 
    field2 int, 
    ... 
); 

INSERT INTO new_tbl(field1, field2, ...) 
(
    SELECT FROM ... -- use your new logic here to insert the updated data 
) 

CREATE INDEX -- add your constraints and indexes to new_tbl 

DROP TABLE tbl; 

ALTER TABLE tbl_new RENAME tbl; 

1. erstellen neue Tabelle
2. Insert Datensätze aus alter Tabelle auf neue (nehmen weniger als eine Sekunde)
3. Drop alte Tabelle - diese Abfrage hängt für ca. 5 Minuten ~. Musste zurückrollen. Funktioniert nicht für mich.
4. Umbenannt neu erstellte Tabelle auf alte

alte Tabelle Dropping einfach hängt. Wenn ich jedoch versuche, neu erstellte Tabellen mit 1 Million Zeilen zu löschen, funktioniert das sofort. Warum dauert das Ablegen des alten Tisches so viel Zeit?

SELECT blocked_locks.pid  AS blocked_pid, 
     blocked_activity.usename AS blocked_user, 
     blocking_locks.pid  AS blocking_pid, 
     blocking_activity.usename AS blocking_user, 
     blocked_activity.query AS blocked_statement, 
     blocking_activity.query AS blocking_statement 
    FROM pg_catalog.pg_locks   blocked_locks 
    JOIN pg_catalog.pg_stat_activity blocked_activity ON blocked_activity.pid = blocked_locks.pid 
    JOIN pg_catalog.pg_locks   blocking_locks 
     ON blocking_locks.locktype = blocked_locks.locktype 
     AND blocking_locks.DATABASE IS NOT DISTINCT FROM blocked_locks.DATABASE 
     AND blocking_locks.relation IS NOT DISTINCT FROM blocked_locks.relation 
     AND blocking_locks.page IS NOT DISTINCT FROM blocked_locks.page 
     AND blocking_locks.tuple IS NOT DISTINCT FROM blocked_locks.tuple 
     AND blocking_locks.virtualxid IS NOT DISTINCT FROM blocked_locks.virtualxid 
     AND blocking_locks.transactionid IS NOT DISTINCT FROM blocked_locks.transactionid 
     AND blocking_locks.classid IS NOT DISTINCT FROM blocked_locks.classid 
     AND blocking_locks.objid IS NOT DISTINCT FROM blocked_locks.objid 
     AND blocking_locks.objsubid IS NOT DISTINCT FROM blocked_locks.objsubid 
     AND blocking_locks.pid != blocked_locks.pid 
    JOIN pg_catalog.pg_stat_activity blocking_activity ON blocking_activity.pid = blocking_locks.pid 
    WHERE NOT blocked_locks.granted; 

Ich kann viele gleichzeitige Schreib-/Lesevorgänge sehen, die auf meine Operation warten. Seit ich das Schloss auf den Tisch genommen habe, glaube ich nicht wirklich, dass ich den alten Tisch nicht fallen lassen kann.

Nur Vakuum auf alten Tisch laufen, es hat nicht geholfen.

Warum kann ich die alte Tabelle nicht löschen, warum es so viel Zeit in Anspruch nimmt im Vergleich zum Löschen der zuletzt erstellten Tabelle?

Answer 1

Ich konnte Tabelle ursprüngliche Tabelle Ursache von FK anderer Tabellen nicht löschen/umbenennen. Sobald ich es dropoed, Ansatz mit Umbenennungstabelle funktioniert super

Answer 2

Ich habe nicht viel Erfahrung mit PostgreSQL, aber meine Vermutung ist, dass es ein wenig hält, um anzuzeigen, wenn eine NULL Lage Spalte NULL ist (im Gegensatz zu leeren Gegensatz), und wenn diese Spalte als NOT NULL es markiert nicht länger braucht das bisschen. Wenn Sie also dieses Attribut für eine Spalte ändern, muss das System die gesamte Tabelle durchlaufen und die Daten neu anordnen, wobei viele Bits verschoben werden, damit die Zeilen alle richtig strukturiert sind.

Dies unterscheidet sich sehr von einem DROP TABLE, der lediglich den Speicherplatz als nicht mehr verwendet markieren und möglicherweise einige Metadatenwerte aktualisieren muss.

Kurz gesagt, sie sind sehr unterschiedliche Aktionen, so natürlich sie unterschiedliche Mengen an Zeit in Anspruch nehmen.