È sicuro utilizzare il partizionamento delle tabelle Postgres con vincoli sovrapposti?

Question

Postgres documentazione dice che le condizioni in partizioni della tabella non devono sovrapporsi

Assicurarsi che i vincoli garantiscono che non v'è sovrapposizione tra i valori chiave permesso in partizioni diverse.

ma non capisco il motivo per cui, a causa di partizione precisa che i dati da inserire in è ancora deciso dal grilletto, che potrebbe essere a conoscenza di sovrapposizione vincoli

ho la seguente situazione, un tavolo con un sacco di informazioni sul testo e data/ora update_date, questa tabella è partizionata per trimestre, e tutte le righe nuove o aggiornate vanno nella partizione più recente, il problema è che l'indice gin trigram è troppo lento, quindi voglio evitare di costruire indice trigramma per il giorno corrente

al momento il trigger sulla tabella master è responsabile della creazione di parti in modo dinamico, sto pianificando di aggiungere una nuova partizione per il giorno corrente, che si sovrapporrà alla partizione del quarto e voglio disabilitare l'indice trigram per la partizione del giorno corrente (unire i dati nella partizione del quarto sarebbe un'altra attività di manutenzione)

Ho provato a creare le tabelle di partizione manualmente con i vincoli update_date sovrapposti e postgres non si sono lamentati, ho persino eseguito la ricerca e entrambe le tabelle sono state utilizzate nel piano, quindi sembra funzionare bene, tuttavia la documentazione dice che i vincoli possono t si sovrappongono, perché è quello?

è sicuro creare partizioni con vincoli sovrapposti se si dispone di trigger e manutenzione corretti?

UPD:

CREATE TABLE master (text_value text, update_date timestamp); 

CREATE TABLE partition_year (
    CHECK (update_date >= DATE '2015-01-01' AND update_date < DATE '2015-12-31') 
) INHERITS (master); 

CREATE TABLE partition_month (
    CHECK (update_date >= DATE '2015-07-01' AND update_date < DATE '2015-8-01') 
) INHERITS (master); 

-- in production this would be handled by trigger 
insert into partition_year(text_value, update_date) values ('year', '2015-01-02'); 
insert into partition_month(text_value, update_date) values ('month', '2015-07-02'); 

-- this scans only year partition 
explain select * from master where update_date = '2015-01-02'; 

-- this scans both year and month partition 
explain select * from master where update_date = '2015-07-02'; 

questo esempio mostra che postgres legge sia l'anno e il mese partititon e non si cura molto circa la loro sovrapposizione

Answer 1

Suppongo che si può fare. La documentazione spiega solo il concetto di partizionamento come caso privato di ereditarietà delle tabelle. Ci possono essere diverse implementazioni nella tua applicazione. Ad esempio, è possibile creare partizioni e decidere quale utilizzare per l'inserimento dal codice senza utilizzare i trigger nel db stesso. In questi casi questi controlli nel db sono una misura di sicurezza.