Kevin Grittner kgri...@ymail.com wrote:
Noah Misch n...@leadboat.com wrote:
Also, could you explain the use of RelationCacheInvalidateEntry()
in ExecRefreshMatView()? CacheInvalidateRelcacheByRelid()
followed by CommandCounterIncrement() is the typical pattern;
this is novel. I suspect,
Apologies, but this sub-thread got lost when I changed email
accounts. I found it in a final review to make sure nothing had
fallen through the cracks.
Noah Misch n...@leadboat.com wrote:
On Thu, Jan 24, 2013 at 01:09:28PM -0500, Noah Misch wrote:
There's no documented support for table
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.
On Wed, Mar 6, 2013 at 09:16:59AM -0500, Tom Lane wrote:
Simon Riggs si...@2ndquadrant.com writes:
On 5 March 2013 22:02, Tom Lane t...@sss.pgh.pa.us wrote:
FWIW, my opinion is that doing anything like this in the planner is
going to be enormously expensive.
As we already said: no MVs
On Tue, Mar 5, 2013 at 08:50:39AM +, Simon Riggs wrote:
Its not a different feature, its what most people expect a feature
called MV to deliver. That's not a matter of opinion, its simply how
every other database works currently - Oracle, Teradata, SQLServer at
least. The fact that we
On Thu, Mar 7, 2013 at 12:14 PM, David E. Wheeler da...@justatheory.com wrote:
On Mar 7, 2013, at 7:55 AM, Kevin Grittner kgri...@ymail.com wrote:
If the answer to both those questions is “yes,” I think the term
should remain “table,” with a few mentions that the term includes
materialized
On 6 March 2013 14:16, Tom Lane t...@sss.pgh.pa.us wrote:
Simon Riggs si...@2ndquadrant.com writes:
On 5 March 2013 22:02, Tom Lane t...@sss.pgh.pa.us wrote:
FWIW, my opinion is that doing anything like this in the planner is
going to be enormously expensive.
As we already said: no MVs =
David E. Wheeler da...@justatheory.com wrote:
Kevin Grittner kgri...@ymail.com wrote:
I also think that something should be done about the
documentation for indexes. Right now that always refers to a
table. It would clearly be awkward to change that to table
or materialized view
On Mar 7, 2013, at 7:55 AM, Kevin Grittner kgri...@ymail.com wrote:
If the answer to both those questions is “yes,” I think the term
should remain “table,” with a few mentions that the term includes
materialized views (and excludes foreign tables).
And if the answers are not exactly and
2013/3/5 Kevin Grittner kgri...@ymail.com:
Perhaps it would be worth looking for anything in the patch that
you think might be painting us into a corner where it would be hard
to do all the other cool things. While it's late enough in the
process that changing anything like that which you
On 5 March 2013 22:02, Tom Lane t...@sss.pgh.pa.us wrote:
FWIW, my opinion is that doing anything like this in the planner is
going to be enormously expensive. Index matching is already pretty
expensive, and that has the saving grace that we only do it once per
base relation. Your sketch
Simon Riggs si...@2ndquadrant.com writes:
On 5 March 2013 22:02, Tom Lane t...@sss.pgh.pa.us wrote:
FWIW, my opinion is that doing anything like this in the planner is
going to be enormously expensive.
As we already said: no MVs = zero overhead = no problem.
Well, in the first place that
Tatsuo Ishii is...@postgresql.org wrote:
Was the remaining work on docs done? I would like to test MVs and
am waiting for the docs completed.
I think they are done. If you notice anything missing or in need
of clarification please let me know. At this point missing docs
would be a bug in
Kevin,
I haven't seen a reply to this. Were you able to give my notes below
any consideration?
On 2/15/13 12:44 PM, Peter Eisentraut wrote:
On 1/25/13 1:00 AM, Kevin Grittner wrote:
New patch rebased, fixes issues raised by Thom Brown, and addresses
some of your points.
This patch
On Tue, Mar 5, 2013 at 9:08 PM, Robert Haas robertmh...@gmail.com wrote:
All that having been said, it's hard for me to imagine that anyone
really cares about any of this until we have an incremental update
feature, which right now we don't. Actually, I'm betting that's going
to be
Kevin Grittner kgri...@ymail.com wrote:
Tatsuo Ishii is...@postgresql.org wrote:
Was the remaining work on docs done? I would like to test MVs and
am waiting for the docs completed.
I think they are done. If you notice anything missing or in need
of clarification please let me know. At
On Mar 6, 2013, at 1:51 PM, Kevin Grittner kgri...@ymail.com wrote:
I also think that something should be done about the documentation
for indexes. Right now that always refers to a table. It would
clearly be awkward to change that to table or materialized view
everywhere. I wonder if most
Kevin Grittner kgri...@ymail.com wrote:
Tatsuo Ishii is...@postgresql.org wrote:
Was the remaining work on docs done? I would like to test MVs and
am waiting for the docs completed.
I think they are done. If you notice anything missing or in need
of clarification please let me know. At
On 3 March 2013 23:39, Tom Lane t...@sss.pgh.pa.us wrote:
Nicolas Barbier nicolas.barb...@gmail.com writes:
2013/3/3 Kevin Grittner kgri...@ymail.com:
Nicolas Barbier nicolas.barb...@gmail.com wrote:
I think that automatically using materialized views even when the
query doesn’t mention them
Simon Riggs si...@2ndquadrant.com wrote:
On 3 March 2013 23:39, Tom Lane t...@sss.pgh.pa.us wrote:
Nicolas Barbier nicolas.barb...@gmail.com writes:
2013/3/3 Kevin Grittner kgri...@ymail.com:
Nicolas Barbier nicolas.barb...@gmail.com wrote:
I think that automatically using materialized views
On 5 March 2013 12:15, Kevin Grittner kgri...@ymail.com wrote:
I don't think I disagree with any of what Simon says other than his
feelings about the planning cost. Imagine that there are ten MVs
that might apply to a complex query, but some of them are mutually
exclusive, so there are a
Simon, Kevin, all:
Actually, there was already an attempt at automated MV query planning as
a prior university project. We could mine that for ideas.
Hmmm. I thought it was on pgfoundry, but it's not. Does anyone have
access to ACM databases etc. so they could search for this?
--
Josh
On Tue, Mar 5, 2013 at 7:15 AM, Kevin Grittner kgri...@ymail.com wrote:
I don't think I disagree with any of what Simon says other than his
feelings about the planning cost. Imagine that there are ten MVs
that might apply to a complex query, but some of them are mutually
exclusive, so there
Josh Berkus j...@agliodbs.com wrote:
There is no shortage of literature on the topic, although any
papers from the ACM could certainly be of interest due to the
general high quality of papers published there. Adding anything
like this to 9.3 is clearly out of the question, though, so I
really
Robert Haas robertmh...@gmail.com wrote:
All that having been said, it's hard for me to imagine that
anyone really cares about any of this until we have an
incremental update feature, which right now we don't.
These are actually independent of one another, as long as we nail
down how we're
2013/3/5 Robert Haas robertmh...@gmail.com:
All that having been said, it's hard for me to imagine that anyone
really cares about any of this until we have an incremental update
feature, which right now we don't. Actually, I'm betting that's going
to be significantly harder than
Robert Haas robertmh...@gmail.com writes:
On Tue, Mar 5, 2013 at 7:15 AM, Kevin Grittner kgri...@ymail.com wrote:
I don't think I disagree with any of what Simon says other than his
feelings about the planning cost.
I'm not sure I agree. Suppose you have a query like SELECT * FROM a
INNER
2013/3/5 Kevin Grittner kgri...@ymail.com:
Exactly. I predict that we will eventually have some special sort
of trigger for maintaining MVs based on base table changes to
handle the ones that are just too expensive (in developer time or
run time) to fully automate. But there is a lot of
Nicolas Barbier nicolas.barb...@gmail.com wrote:
PS. Sorry for having fired off this discussion that obviously
doesn’t really relate to the current patch.
I know it's hard to resist. While I think there will be a number
of people for whom the current patch will be a convenience and will
On 03/05/2013 01:09 PM, Kevin Grittner wrote:
Josh Berkus j...@agliodbs.com wrote:
There is no shortage of literature on the topic, although any
papers from the ACM could certainly be of interest due to the
general high quality of papers published there. Adding anything
like this to 9.3 is
Kevin Grittner kgri...@ymail.com wrote:
REFRESH MATERIALIZED VIEW name [, ...] WITH [ NO ] DATA
Given the short time, I left out the [, ...]. If people think
that is important to get into this release, a follow-on patch might
be possible.
Barring objections, I will use the above and
On 03-03-2013 21:27, Josh Berkus wrote:
I think it would be worth talking about when someone wants to implement
it. I'd imagine it would require setting a GUC, though, which would be
off by default for obvious reasosn.
-1. Why not adding another storage_parameter, say auto_refresh=on? Also,
On 2 March 2013 15:06, Kevin Grittner kgri...@ymail.com wrote:
[ ... ] led to
this thought:
REFRESH MATERIALIZED VIEW name [, ...] WITH [ NO ] DATA
[Sorry to join this discussion so late]
FWIW I had a quick look at other DBs to see if there were any other
precedents out there. Oracle was
Dean Rasheed dean.a.rash...@gmail.com wrote:
Kevin Grittner kgri...@ymail.com wrote:
[ ... ] led to this thought:
REFRESH MATERIALIZED VIEW name [, ...] WITH [ NO ] DATA
[Sorry to join this discussion so late]
FWIW I had a quick look at other DBs to see if there were any
other precedents
On 3 March 2013 13:12, Kevin Grittner kgri...@ymail.com wrote:
Dean Rasheed dean.a.rash...@gmail.com wrote:
Kevin Grittner kgri...@ymail.com wrote:
[ ... ] led to this thought:
REFRESH MATERIALIZED VIEW name [, ...] WITH [ NO ] DATA
[Sorry to join this discussion so late]
FWIW I had a
2013/3/3 Kevin Grittner kgri...@ymail.com:
Rewriting queries using
expressions which match the MV's query to pull from the MV instead
of the underlying tables is the exception. While that is a sexy
feature, and I'm sure one can construct examples where it helps
performance, it seems to me
Nicolas Barbier nicolas.barb...@gmail.com wrote:
2013/3/3 Kevin Grittner kgri...@ymail.com:
Rewriting queries using expressions which match the MV's query
to pull from the MV instead of the underlying tables is the
exception. While that is a sexy feature, and I'm sure one can
construct
On Sat, Mar 2, 2013 at 3:06 PM, Kevin Grittner kgri...@ymail.com wrote:
(1) Any DML against the MV would need to be limited to some
context fired by the underlying changes. If we allow changes to
the MV outside of that without it being part of some updateable
MV feature (reversing the
2013/3/3 Kevin Grittner kgri...@ymail.com:
Nicolas Barbier nicolas.barb...@gmail.com wrote:
I think that automatically using materialized views even when the
query doesn’t mention them directly, is akin to automatically
using indexes without having to mention them in the query. That
way,
Nicolas Barbier nicolas.barb...@gmail.com writes:
2013/3/3 Kevin Grittner kgri...@ymail.com:
Nicolas Barbier nicolas.barb...@gmail.com wrote:
I think that automatically using materialized views even when the
query doesnât mention them directly, is akin to automatically
using indexes without
There's a much more fundamental reason why this will never happen, which
is that the query planner is not licensed to decide that you only want
an approximate and not an exact answer to your query.
I think it would be worth talking about when someone wants to implement
it. I'd imagine it
Kevin Grittner kgri...@ymail.com wrote:
I'm still working on docs, and the changes related to the syntax
change are still only lightly tested, but as far as I know, all is
complete except for the docs. I'm still working on those and
expect to have them completed late today. I'm posting this
On 03/04/2013 08:27 AM, Josh Berkus wrote:
There's a much more fundamental reason why this will never happen, which
is that the query planner is not licensed to decide that you only want
an approximate and not an exact answer to your query.
I think it would be worth talking about when someone
On Fri, Mar 1, 2013 at 3:01 PM, Ants Aasma a...@cybertec.at wrote:
. To give another example of potential future
update semantics, if we were to allow users manually maintaining
materialized view contents using DML commands, one would expect
TRUNCATE to mean make this matview empty, not make
Greg Stark st...@mit.edu wrote:
Ants Aasma a...@cybertec.at wrote:
To give another example of potential future update semantics, if
we were to allow users manually maintaining materialized view
contents using DML commands, one would expect TRUNCATE to mean
make this matview empty, not make
On Thu, Feb 28, 2013 at 7:52 PM, Kevin Grittner kgri...@ymail.com wrote:
Barring a sudden confluence of opinion, I will go with TRUNCATE for
the initial spelling. I tend to favor that spelling for several
reasons. One was the size of the patch needed to add the opposite
of REFRESH to the
Ants Aasma a...@cybertec.at wrote:
Kevin Grittner kgri...@ymail.com wrote:
Barring a sudden confluence of opinion, I will go with TRUNCATE
for the initial spelling. I tend to favor that spelling for
several reasons. One was the size of the patch needed to add
the opposite of REFRESH to the
On Fri, Mar 1, 2013 at 4:18 PM, Kevin Grittner kgri...@ymail.com wrote:
Personally, I don't understand why anyone would want updateable
materialized views. That's probably because 99% of the cases where
I've seen that someone wanted them, they wanted them updated to
match the underlying data
On Sat, Feb 23, 2013 at 8:00 AM, Michael Paquier
michael.paqu...@gmail.com wrote:
it is. http://www.postgresql.org/docs/9.2/static/sql-reset.html
DISCARD would be better.
Well, personally, I'm in favor of either TRUNCATE or ALTER
MATERIALIZED VIEW ... DISCARD. I think it's a dangerous
Robert Haas robertmh...@gmail.com writes:
On Sat, Feb 23, 2013 at 8:00 AM, Michael Paquier
michael.paqu...@gmail.com wrote:
it is. http://www.postgresql.org/docs/9.2/static/sql-reset.html
DISCARD would be better.
Well, personally, I'm in favor of either TRUNCATE or ALTER
MATERIALIZED VIEW
On 28.02.2013 16:55, Robert Haas wrote:
On Sat, Feb 23, 2013 at 8:00 AM, Michael Paquier
michael.paqu...@gmail.com wrote:
it is. http://www.postgresql.org/docs/9.2/static/sql-reset.html
DISCARD would be better.
Well, personally, I'm in favor of either TRUNCATE or ALTER
MATERIALIZED VIEW ...
On Thu, Feb 28, 2013 at 11:00 AM, Tom Lane t...@sss.pgh.pa.us wrote:
Well, personally, I'm in favor of either TRUNCATE or ALTER
MATERIALIZED VIEW ... DISCARD. I think it's a dangerous precedent to
suppose that we're going to start using DISCARD for things that have
nothing to do with the
Heikki Linnakangas hlinnakan...@vmware.com wrote:
On 28.02.2013 16:55, Robert Haas wrote:
Well, personally, I'm in favor of either TRUNCATE or ALTER
MATERIALIZED VIEW ... DISCARD. I think it's a dangerous
precedent to suppose that we're going to start using DISCARD for
things that have
2013-02-19 Kevin Grittner wrote:
[matview-system_views-v2.diff]
I assumed the patches matview-v4.patch and matview-system_views-v2.diff
were to be applied together.
They do apply correctly but during tests, the test rules ... FAILED.
Perhaps it is solved already but I thought I'd mention
On Sat, Feb 23, 2013 at 1:00 AM, Josh Berkus j...@agliodbs.com wrote:
I prefer RESET, especially since it could eventually support RESET ALL
MATERIALIZED VIEWS if that turns out to be useful. How does the parser
like that?
Isn't reset currently only used for GUCs? I think that makes for a
On Sat, Feb 23, 2013 at 9:55 PM, Greg Stark st...@mit.edu wrote:
On Sat, Feb 23, 2013 at 1:00 AM, Josh Berkus j...@agliodbs.com wrote:
I prefer RESET, especially since it could eventually support RESET ALL
MATERIALIZED VIEWS if that turns out to be useful. How does the parser
like that?
Andres Freund and...@2ndquadrant.com writes:
On 2013-02-21 14:11:10 -0800, Kevin Grittner wrote:
DISABLE MATERIALIZED VIEW mv; -- ALTER clause for constraints
DISCARD MATERIALIZED VIEW DATA mv; -- session state
RELEASE MATERIALIZED VIEW DATA mv; -- savepoint
RESET MATERIALIZED VIEW DATA
That feels completely wrong to me. For one thing, I can't think of
any ALTER commands to populate or remove data. What did you think
of the idea of something like DISCARD MATERIALIZED VIEW DATA as a
new statment? Or maybe RESET MATERIALIZED VIEW?
I prefer RESET, especially since it could
Greg Stark st...@mit.edu writes:
The way I was thinking about it, whatever the command is named, you
might be able to tell the database to drop the storage associated with
the view but that would make the view invalid until it was refreshed.
It wouldn't make it appear to be empty.
Actually,
On 2013-02-21 04:14:09 +, Greg Stark wrote:
On Wed, Feb 20, 2013 at 9:25 PM, Peter Eisentraut pete...@gmx.net wrote:
More generally, I would consider the invalidation of a materialized view
a DDL command, whereas truncating a table is a DML command.
That's not entirely true. From the
On Wed, Feb 20, 2013 at 11:14 PM, Greg Stark st...@mit.edu wrote:
On Wed, Feb 20, 2013 at 9:25 PM, Peter Eisentraut pete...@gmx.net wrote:
More generally, I would consider the invalidation of a materialized view
a DDL command, whereas truncating a table is a DML command.
That's not entirely
On 2/20/13 5:03 PM, Kevin Grittner wrote:
Peter Eisentraut pete...@gmx.net wrote:
On 2/20/13 2:30 PM, Kevin Grittner wrote:
Are there TRUNCATE triggers on materialized views?
No. Nor SELECT, INSERT, UPDATE, or DELETE triggers. You can't
create a trigger of any type on a materialized view.
On 2/20/13 11:14 PM, Greg Stark wrote:
That's not entirely true. From the database's point of view, TRUNCATE
is in many ways actually DDL.
Whether something is DDL or DML or a read operation (query) is not an
implementation detail, it's a user-exposed category. Since TRUNCATE is
logically
Peter Eisentraut pete...@gmx.net wrote:
On 2/20/13 11:14 PM, Greg Stark wrote:
That's not entirely true. From the database's point of view,
TRUNCATE is in many ways actually DDL.
Whether something is DDL or DML or a read operation (query) is
not an implementation detail, it's a user-exposed
Tom Lane t...@sss.pgh.pa.us wrote:
Greg Stark st...@mit.edu writes:
The way I was thinking about it, whatever the command is named, you
might be able to tell the database to drop the storage associated with
the view but that would make the view invalid until it was refreshed.
It wouldn't make
Greg Stark st...@mit.edu wrote:
I actually don't really dislike using TRUNCATE for this
command. I was more asking about whether this meant people were
thinking of the view as a thing where you could control the data
in it by hand and could have the view be empty rather than just
not valid.
Peter Eisentraut pete...@gmx.net wrote:
I'll need more time to ponder your other points, but...
You don't need a new command or key word for this. How about
ALTER MATERIALIZED VIEW DISCARD?
I don't like this because we don't have ALTER TABLE REINDEX. But
the fact that DISCARD is a keyword
On 21.02.2013 16:38, Kevin Grittner wrote:
Tom Lanet...@sss.pgh.pa.us wrote:
Greg Starkst...@mit.edu writes:
The way I was thinking about it, whatever the command is named, you
might be able to tell the database to drop the storage associated with
the view but that would make the view
Andres Freund and...@2ndquadrant.com wrote:
giving an error so its an easy to find distinction to a normal
table seems like a good idea.
I'm not sure I understood your concerns entirely, but wonder
whether this helps?:
test=# \d
List of relations
Schema | Name | Type
Kevin Grittner kgri...@ymail.com writes:
Tom Lane t...@sss.pgh.pa.us wrote:
That being the case, lumping them as being the same operation
feels like the wrong thing, and so we should choose a different
name for the MV operation.
There is currently no truncation of MV data without rendering
Heikki Linnakangas hlinnakan...@vmware.com wrote:
On 21.02.2013 16:38, Kevin Grittner wrote:
Tom Lanet...@sss.pgh.pa.us wrote:
Greg Starkst...@mit.edu writes:
The way I was thinking about it, whatever the command is named, you
might be able to tell the database to drop the storage
On 2013-02-21 07:10:09 -0800, Kevin Grittner wrote:
Andres Freund and...@2ndquadrant.com wrote:
giving an error so its an easy to find distinction to a normal
table seems like a good idea.
I'm not sure I understood your concerns entirely, but wonder
whether this helps?:
To explain it a
Tom Lane t...@sss.pgh.pa.us wrote:
Kevin Grittner kgri...@ymail.com writes:
Tom Lane t...@sss.pgh.pa.us wrote:
That being the case, lumping them as being the same
operation feels like the wrong thing, and so we should choose a
different name for the MV operation.
There is currently no
Andres Freund and...@2ndquadrant.com wrote:
I assume that at some point matviews will get (auto-)updateable,
just as normal views recently got.
I'm dubious about that. Every use case I've seen for MVs involves
aggregation, although they are a generalized feature, so that won't
always be true.
Kevin Grittner kgri...@ymail.com writes:
Tom Lane t...@sss.pgh.pa.us wrote:
Peter claimed upthread that REFRESH is a subcommand of ALTER
MATERIALIZE VIEW
It's not, nor do I think it should be.
Oh, never mind then.
and that this operation should be another one. That sounds
pretty
On 2/21/13 9:25 AM, Kevin Grittner wrote:
Peter Eisentraut pete...@gmx.net wrote:
On 2/20/13 11:14 PM, Greg Stark wrote:
That's not entirely true. From the database's point of view,
TRUNCATE is in many ways actually DDL.
Whether something is DDL or DML or a read operation (query) is
not an
Tom Lane t...@sss.pgh.pa.us wrote:
Kevin Grittner kgri...@ymail.com writes:
What did you think of the idea of something like DISCARD
MATERIALIZED VIEW DATA as a new statment? Or maybe RESET
MATERIALIZED VIEW?
I could live with either DISCARD or RESET.
I figured this was worth a pass
On Thu, Feb 21, 2013 at 2:38 PM, Kevin Grittner kgri...@ymail.com wrote:
It doesn't. That was one of the more contentious points in the
earlier bikeshedding phases. Some felt that throwing away the
contents was a form of making the MV out of date and as such
didn't require any special
Greg Stark st...@mit.edu wrote:
Kevin Grittner kgri...@ymail.com wrote:
It doesn't. That was one of the more contentious points in the
earlier bikeshedding phases. Some felt that throwing away the
contents was a form of making the MV out of date and as such
didn't require any special
On 2013-02-21 14:11:10 -0800, Kevin Grittner wrote:
Tom Lane t...@sss.pgh.pa.us wrote:
Kevin Grittner kgri...@ymail.com writes:
What did you think of the idea of something like DISCARD
MATERIALIZED VIEW DATA as a new statment? Or maybe RESET
MATERIALIZED VIEW?
I could live with
Kevin Grittner kgri...@ymail.com writes:
When I went to do this, I hit a shift/reduce conflict, because with
TABLE being optional it couldn't tell whether:
TRUNCATE MATERIALIZED VIEW x, y, z;
... was looking for five relations or three. That goes away with
MATERIALIZED escalated to
On Tue, Feb 19, 2013 at 11:01 AM, Peter Eisentraut pete...@gmx.net wrote:
On 2/19/13 8:54 AM, Robert Haas wrote:
In the department of crazy ideas, what about having pg_dump NEVER
refresh ANY materialized views?
It might be useful to have an option for this, but I don't think it
should be the
Robert Haas robertmh...@gmail.com writes:
On Tue, Feb 19, 2013 at 11:01 AM, Peter Eisentraut pete...@gmx.net wrote:
This might be different if there were a command to refresh all
materialized views, because you don't want to have to go around and type
separate commands 47 times after a
On 2/19/13 5:22 PM, David Fetter wrote:
On Tue, Feb 19, 2013 at 11:09:13PM +0100, Erik Rijkers wrote:
On Sat, February 16, 2013 02:01, Kevin Grittner wrote:
matview-v4.patch.gz
Hi,
I was wondering if material views should not go into information_schema. I
was thinking either
.views or
Tom Lane t...@sss.pgh.pa.us wrote:
Kevin Grittner kgri...@ymail.com writes:
When I went to do this, I hit a shift/reduce conflict, because
with TABLE being optional it couldn't tell whether:
TRUNCATE MATERIALIZED VIEW x, y, z;
... was looking for five relations or three. That goes away
Peter Eisentraut pete...@gmx.net wrote:
I suppose one should be able to expect that if one finds a view
in the information schema, then one should be able to use DROP
VIEW to remove it. Which in this case wouldn't work. So I don't
think including a materialized view under views or tables is
Kevin Grittner kgri...@ymail.com writes:
Tom Lane t...@sss.pgh.pa.us wrote:
Having said that, I don't think I believe your analysis of why
this doesn't work.
Well, it wouldn't be the first time you've seen a better way to do
something in flex than I was able to see. Taking just the gram.y
Tom Lane t...@sss.pgh.pa.us wrote:
The way to fix it is to not try to use the sub-production but spell it
all out:
TRUNCATE TABLE relation_expr_list ...
| TRUNCATE MATERIALIZED VIEW relation_expr_list ...
| TRUNCATE relation_expr_list ...
Now the parser doesn't have to
On 2/20/13 6:13 AM, Robert Haas wrote:
It might be useful to have an option for this, but I don't think it
should be the default. The default should be that the new database is
ready to go.
Then again, when would you ever actually use that option?
You'd use that option if you'd rather
On Wed, February 20, 2013 16:28, Kevin Grittner wrote:
Peter Eisentraut pete...@gmx.net wrote:
I suppose one should be able to expect that if one finds a view
in the information schema, then one should be able to use DROP
VIEW to remove it. Which in this case wouldn't work. So I don't
On Wed, Feb 20, 2013 at 4:26 PM, Kevin Grittner kgri...@ymail.com wrote:
Tom Lane t...@sss.pgh.pa.us wrote:
The way to fix it is to not try to use the sub-production but spell it
all out:
TRUNCATE TABLE relation_expr_list ...
| TRUNCATE MATERIALIZED VIEW relation_expr_list ...
Greg Stark st...@mit.edu wrote:
Kevin Grittner kgri...@ymail.com wrote:
Tom Lane t...@sss.pgh.pa.us wrote:
The way to fix it is to not try to use the sub-production but
spell it all out:
TRUNCATE TABLE relation_expr_list ...
| TRUNCATE MATERIALIZED VIEW relation_expr_list ...
And explicitly not support
1) Automatically rewriting queries to select from matching views
2) Incrementally refreshing materialized views
3) Manual DML against data in materialized views (except truncate
which is kind of DDL)
4) Keeping track of whether the data in the materialized view
On 2/19/13 5:47 PM, Kevin Grittner wrote:
When I went to do this, I hit a shift/reduce conflict, because with
TABLE being optional it couldn't tell whether:
TRUNCATE MATERIALIZED VIEW x, y, z;
... was looking for five relations or three. That goes away with
MATERIALIZED escalated to
Peter Eisentraut pete...@gmx.net wrote:
On 2/19/13 5:47 PM, Kevin Grittner wrote:
When I went to do this, I hit a shift/reduce conflict, because
with TABLE being optional it couldn't tell whether:
TRUNCATE MATERIALIZED VIEW x, y, z;
... was looking for five relations or three. That goes
* Kevin Grittner (kgri...@ymail.com) wrote:
Peter Eisentraut pete...@gmx.net wrote:
Is TRUNCATE even the right command here? For regular tables
TRUNCATE is a fast DELETE, which logically empties the table.
For materialized views, there is no deleting, so this command (I
suppose?) just
On 2/20/13 2:30 PM, Kevin Grittner wrote:
Are there TRUNCATE triggers on materialized views?
No. Nor SELECT, INSERT, UPDATE, or DELETE triggers. You can't
create a trigger of any type on a materialized view. I don't think
that would interfere with event triggers, though.
More generally, I
Peter Eisentraut pete...@gmx.net wrote:
On 2/20/13 2:30 PM, Kevin Grittner wrote:
Are there TRUNCATE triggers on materialized views?
No. Nor SELECT, INSERT, UPDATE, or DELETE triggers. You can't
create a trigger of any type on a materialized view. I don't
think that would interfere with
I would like to know what operations you plan to support independently
of the command names. I may have missed much earlier in the discussion
but then I suspect things have evolved since then.
It sounds like you want to support:
1) Selecting from materialized viws
2) Manually refreshing
On Wed, Feb 20, 2013 at 9:25 PM, Peter Eisentraut pete...@gmx.net wrote:
More generally, I would consider the invalidation of a materialized view
a DDL command, whereas truncating a table is a DML command.
That's not entirely true. From the database's point of view, TRUNCATE
is in many ways
1 - 100 of 204 matches
Mail list logo
