Partitionierung v. Tabellen mit großen default partitions (BUG?)

hallo,

warum kann die anlage von weiteren partition tables für die zukunft ( partition by range date / 1 tag)
extrem lange dauern und massiv ressourcen belegen?

anscheind ausgelöst durch scans der basistabelle bzw. der default partition welche aufgrund
fehlender partitions im zwischenzeitraum sehr groß geworden ist.

f. postgres sollte doch klar sein das, dass create table xxx partition of yyy … ddl die
inhalte vorhandener partitions nicht berücksichtigen muß da deren ranges in der zukunft liegen?

jedes create table xxx partiton of yyy dauert in unserem fall ca. 60 min ! was passiert hier?

warum ist diese laufzeit anscheinendd von der datenmenge in der default partition abhängig?

danke.

die Default-Partition hat halt Constraints, und zwar die Ausschlußmenge der Constraints der anderen Partitions. Wenn diese Default-Partition recht groß ist kann ich mir schon vorstellen, daß das dauert.

Für Kunden von uns haben wir einen KnowledgeBase-Artikel für sowas :wink:

okay, in kurz: in einer TX die default sperren, neue Kindtabelle erstellen, with moving as (delete from default … returnig *) insert into new select * from moving; und dann die neue Kindtabelle via attach an die Elterntabelle hängen.