From: | Noah Misch <noah(at)leadboat(dot)com> |
---|---|
To: | Kevin Grittner <kgrittn(at)mail(dot)com> |
Cc: | Pgsql Hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Materialized views WIP patch |
Date: | 2013-07-14 20:45:26 |
Message-ID: | 20130714204526.GB11636@tornado.leadboat.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
While doing some post-commit review of the 9.3 materialized view feature, I
noticed a few loose ends:
On Thu, Jan 24, 2013 at 01:09:28PM -0500, Noah Misch wrote:
> Note that [...] "ALTER TABLE ... RENAME CONSTRAINT" [is]
> currently supported for MVs by ALTER TABLE but not by ALTER MATERIALIZED VIEW.
>
> There's no documented support for table constraints on MVs, but UNIQUE
> constraints are permitted:
>
> [local] test=# alter materialized view mymv add unique (c);
> ALTER MATERIALIZED VIEW
> [local] test=# alter materialized view mymv add check (c > 0);
> ERROR: "mymv" is not a table
> [local] test=# alter materialized view mymv add primary key (c);
> ERROR: "mymv" is not a table or foreign table
The above points still apply.
Also, could you explain the use of RelationCacheInvalidateEntry() in
ExecRefreshMatView()? CacheInvalidateRelcacheByRelid() followed by
CommandCounterIncrement() is the typical pattern; this is novel. I suspect,
though, neither is necessary now that the relcache does not maintain populated
status based on a fork size reading.
Thanks,
nm
--
Noah Misch
EnterpriseDB http://www.enterprisedb.com
From | Date | Subject | |
---|---|---|---|
Next Message | james | 2013-07-14 21:28:50 | Re: Improvement of checkpoint IO scheduler for stable transaction responses |
Previous Message | Greg Smith | 2013-07-14 20:28:07 | Re: Improvement of checkpoint IO scheduler for stable transaction responses |