Kevin Grittner wrote:
> Noah Misch wrote:
>> 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
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 wrote:
> On Thu, Jan 24, 2013 at 01:09:28PM -0500, Noah Misch wrote:
>> There's no documented support for table constraints on MVs,
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 VI
On Thu, Mar 7, 2013 at 12:14 PM, David E. Wheeler wrote:
> On Mar 7, 2013, at 7:55 AM, Kevin Grittner 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 tabl
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 Wed, Mar 6, 2013 at 09:16:59AM -0500, Tom Lane wrote:
> Simon Riggs writes:
> > On 5 March 2013 22:02, Tom Lane 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 probl
2013/3/5 Kevin Grittner :
> 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 find would be
>
On Mar 7, 2013, at 7:55 AM, Kevin Grittner 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 "yes"?
I s
David E. Wheeler wrote:
> Kevin Grittner 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 of th
On 6 March 2013 14:16, Tom Lane wrote:
> Simon Riggs writes:
>> On 5 March 2013 22:02, Tom Lane 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 fi
> Kevin Grittner wrote:
>> Tatsuo Ishii 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 doc
On Mar 6, 2013, at 1:51 PM, Kevin Grittner 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 of thosse
Kevin Grittner wrote:
> Tatsuo Ishii 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
On Tue, Mar 5, 2013 at 9:08 PM, Robert Haas 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 significantly harder than au
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
Tatsuo Ishii 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 need of a fix.
--
Kev
Simon Riggs writes:
> On 5 March 2013 22:02, Tom Lane 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 statement is false on its face: we'
On 5 March 2013 22:02, Tom Lane 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 above implies try
> Kevin Grittner 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 push t
On 03/05/2013 01:09 PM, Kevin Grittner wrote:
> Josh Berkus 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
Nicolas Barbier 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
therefore use it, it is hard
2013/3/5 Kevin Grittner :
> 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 low-hanging
> fru
Robert Haas writes:
> On Tue, Mar 5, 2013 at 7:15 AM, Kevin Grittner 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 JOIN b ON a.x = b.x INNER JOIN c
2013/3/5 Robert Haas :
> 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 automatic-query-rewrite, when
Robert Haas 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 determining "freshnes
Josh Berkus 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 don't want to spend
On Tue, Mar 5, 2013 at 7:15 AM, Kevin Grittner 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 large num
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 Berku
On 5 March 2013 12:15, Kevin Grittner 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 large number of p
Simon Riggs wrote:
> On 3 March 2013 23:39, Tom Lane wrote:
>> Nicolas Barbier writes:
>>> 2013/3/3 Kevin Grittner :
Nicolas Barbier wrote:
> I think that automatically using materialized views even when
> the query doesn’t mention them directly, is akin to
> automatically usin
On 3 March 2013 23:39, Tom Lane wrote:
> Nicolas Barbier writes:
>> 2013/3/3 Kevin Grittner :
>>> Nicolas Barbier 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
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? Als
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 so
Kevin Grittner 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 patch
> to al
> 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 w
Nicolas Barbier writes:
> 2013/3/3 Kevin Grittner :
>> Nicolas Barbier 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.
>> Oh, I understa
2013/3/3 Kevin Grittner :
> Nicolas Barbier 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, queries can be written the natural
On Sat, Mar 2, 2013 at 3:06 PM, Kevin Grittner 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 direction of flo
Nicolas Barbier wrote:
> 2013/3/3 Kevin Grittner :
>> 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,
2013/3/3 Kevin Grittner :
> 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 unlikely to
On 3 March 2013 13:12, Kevin Grittner wrote:
> Dean Rasheed wrote:
>> Kevin Grittner 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
Dean Rasheed wrote:
> Kevin Grittner 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 the onl
On 2 March 2013 15:06, Kevin Grittner 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 the only one I
Greg Stark wrote:
> Ants Aasma 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 this matview unavai
On Fri, Mar 1, 2013 at 3:01 PM, Ants Aasma 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 this matvie
On Fri, Mar 1, 2013 at 4:18 PM, Kevin Grittner 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 using some tec
Ants Aasma wrote:
> Kevin Grittner 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 backend code:
>
> FWIW, I
On Thu, Feb 28, 2013 at 7:52 PM, Kevin Grittner 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 backend code:
FW
Heikki Linnakangas 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 nothing to do with
On Thu, Feb 28, 2013 at 11:00 AM, Tom Lane 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 existing meanin
On 28.02.2013 16:55, Robert Haas wrote:
On Sat, Feb 23, 2013 at 8:00 AM, Michael Paquier
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 d
Robert Haas writes:
> On Sat, Feb 23, 2013 at 8:00 AM, Michael Paquier
> 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 p
On Sat, Feb 23, 2013 at 8:00 AM, Michael Paquier
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 precedent to
suppose that we're
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 9:55 PM, Greg Stark wrote:
> On Sat, Feb 23, 2013 at 1:00 AM, Josh Berkus 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
On Sat, Feb 23, 2013 at 1:00 AM, Josh Berkus 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
strange crossover.
> 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 cou
Andres Freund 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 mv; -- run-time
On 2013-02-21 14:11:10 -0800, Kevin Grittner wrote:
> Tom Lane wrote:
> > Kevin Grittner 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 RESE
Greg Stark wrote:
> Kevin Grittner 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 handling. Others, includi
On Thu, Feb 21, 2013 at 2:38 PM, Kevin Grittner 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 handling. Others,
Tom Lane wrote:
> Kevin Grittner 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 through the keyword list to look
On 2/21/13 9:25 AM, Kevin Grittner wrote:
> Peter Eisentraut 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 i
Kevin Grittner writes:
> Tom Lane 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 reasonable from here.
> That feel
Andres Freund 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. But if you have a v
Tom Lane wrote:
> Kevin Grittner writes:
>> Tom Lane 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
>
On 2013-02-21 07:10:09 -0800, Kevin Grittner wrote:
> Andres Freund 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 bit:
I assume t
Heikki Linnakangas wrote:
> On 21.02.2013 16:38, Kevin Grittner wrote:
>> Tom Lane wrote:
>>> Greg Stark 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
Kevin Grittner writes:
> Tom Lane 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 the
> MV unscannable. Do y
Andres Freund 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 | Owner
On 21.02.2013 16:38, Kevin Grittner wrote:
Tom Lane wrote:
Greg Stark 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 wou
Peter Eisentraut 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 does open up so
Greg Stark 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".
Y
Tom Lane wrote:
> Greg Stark 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.
Peter Eisentraut 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 category
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 equ
On 2/20/13 5:03 PM, Kevin Grittner wrote:
> Peter Eisentraut 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 d
On Wed, Feb 20, 2013 at 11:14 PM, Greg Stark wrote:
> On Wed, Feb 20, 2013 at 9:25 PM, Peter Eisentraut 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
On 2013-02-21 04:14:09 +, Greg Stark wrote:
> On Wed, Feb 20, 2013 at 9:25 PM, Peter Eisentraut 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
Greg Stark 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, that seems
On Wed, Feb 20, 2013 at 9:25 PM, Peter Eisentraut 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 actually DDL.
I
> 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 refr
Peter Eisentraut 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 event tr
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
* Kevin Grittner (kgri...@ymail.com) wrote:
> Peter Eisentraut 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 invalida
Peter Eisentraut 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 away
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 t
> 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
Greg Stark wrote:
> Kevin Grittner wrote:
>> Tom Lane 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_l
On Wed, Feb 20, 2013 at 4:26 PM, Kevin Grittner wrote:
> Tom Lane 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 relatio
On Wed, February 20, 2013 16:28, Kevin Grittner wrote:
> Peter Eisentraut 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 incl
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 i
Tom Lane 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 make any shif
Kevin Grittner writes:
> Tom Lane 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
> part of the change which imp
Peter Eisentraut 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
> appropria
Tom Lane wrote:
> Kevin Grittner 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 escalat
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 eith
Robert Haas writes:
> On Tue, Feb 19, 2013 at 11:01 AM, Peter Eisentraut 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 restore.
> Well, it's pretty easy to
On Tue, Feb 19, 2013 at 11:01 AM, Peter Eisentraut 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 default
Kevin Grittner 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 TYPE_FUNC_NAME_KEYWO
1 - 100 of 205 matches
Mail list logo
