| From: | Shaun Thomas <shaun(dot)thomas(at)2ndquadrant(dot)com> |
|---|---|
| To: | Rick Otten <rottenwindfish(at)gmail(dot)com> |
| Cc: | "pgsql-performa(dot)" <pgsql-performance(at)postgresql(dot)org> |
| Subject: | Re: partitioning materialized views |
| Date: | 2017-07-07 13:12:58 |
| Message-ID: | CAG1YDPdOvL3cm_1TLEi9ZUsetw0eSPKh57WqfU6-+k2sucuMSw@mail.gmail.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-performance |
> 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(dot)thomas(at)2ndquadrant(dot)com | www.2ndQuadrant.com
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Justin Pryzby | 2017-07-07 23:41:19 | estimate correlation of index separately from table (Re: index fragmentation on insert-only table with non-unique column) |
| Previous Message | Rick Otten | 2017-07-06 16:27:27 | Re: partitioning materialized views |