| From: | "David G(dot) Johnston" <david(dot)g(dot)johnston(at)gmail(dot)com> |
|---|---|
| To: | Tony Cebzanov <tonycpsu(at)gmail(dot)com> |
| Cc: | "pgsql-general(at)postgresql(dot)org" <pgsql-general(at)postgresql(dot)org> |
| Subject: | Re: Constraint exclusion-like behavior for UNION ALL views |
| Date: | 2017-03-29 19:39:09 |
| Message-ID: | CAKFQuwbgNhdFMxDp0hZAi71kdtmQQK37-3K1mJBH-10ocdYZ7w@mail.gmail.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-general |
On Wed, Mar 29, 2017 at 12:19 PM, Tony Cebzanov <tonycpsu(at)gmail(dot)com> wrote:
> Are either of these things that could be supported in the future? If not,
> is there a better way to get this kind of behavior so that materialized
> views are more useful when the amount of data increases and it's not
> feasible to update them in their entirety?
>
The current implementation of materialized views has limitations, some of
which you've listed. Materialized Views can be (and previously were)
manually implemented using triggers - and you can still do so. I recall
seeing some recent blog articles discussing various schemes for
materialized views and their pros and cons.
That said, I'm not sure what using materialized views instead of normal
tables buys you in the first place. I could see possibly using a
materialized view as the current month's table but the historical tables
usually don't require refreshing.
David J.
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Tony Cebzanov | 2017-03-29 19:52:17 | Re: Constraint exclusion-like behavior for UNION ALL views |
| Previous Message | Adrian Klaver | 2017-03-29 19:19:16 | Re: Handling psql lost connections |