MIME-Version: 1.0
In-Reply-To: 
 <CAMAYy4L9msh+hzPwYPVypVrxDPa4U2A0AV_HmwBzO7rY_ThOhA@mail.gmail.com>
References: 
 <CAMAYy4LD9TDO6ohfZwZ7OWOfu3oUZKQxi1Y=qt=36C65DL4jOw@mail.gmail.com>
 <CAG1YDPeH+FBFv9_w1ktPn3JyJNA1F8L_6qaMcRZZQsbBjXtxww@mail.gmail.com>
 <CAMAYy4L=-n=VzyMi6s6tg0PSJcR6mXH2D2K1vk526uLEZkC31A@mail.gmail.com>
 <CAMAYy4L9msh+hzPwYPVypVrxDPa4U2A0AV_HmwBzO7rY_ThOhA@mail.gmail.com>
From: Shaun Thomas <shaun.thomas@2ndquadrant.com>
Date: Fri, 7 Jul 2017 08:12:58 -0500
Message-ID: 
 <CAG1YDPdOvL3cm_1TLEi9ZUsetw0eSPKh57WqfU6-+k2sucuMSw@mail.gmail.com>
Subject: Re: partitioning materialized views
To: Rick Otten <rottenwindfish@gmail.com>
Cc: "pgsql-performa." <pgsql-performance@postgresql.org>
Content-Type: text/plain; charset="UTF-8"
Precedence: bulk
Sender: pgsql-performance-owner@postgresql.org

> I don't think the downstream dependencies will let that work without
> rebuilding them as well.   The drop fails (without a cascade), and the other
> views and matviews that are built off of this all simply point to x_old.

Wow, ouch. Yeah, I'd neglected to consider dependent objects. Your
only "out" at this point is to either add or utilize a "modified_date"
column of some kind, so you can maintain a different MV with some
recent window of data, and regularly merge that into a physical local
copy (not an MV) sort of like a running ETL. Though that won't help
with deletes, unfortunately.

-- 
Shaun M Thomas - 2ndQuadrant
PostgreSQL Training, Services and Support
shaun.thomas@2ndquadrant.com | www.2ndQuadrant.com


-- 
Sent via pgsql-performance mailing list (pgsql-performance@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-performance