2013/3/8 Andres Freund and...@anarazel.de:
On 2013-03-07 15:21:35 -0800, Josh Berkus wrote:
This limitation is in no way crippling for this feature, or even a major
detraction. I still intend to promote the heck out of this feature.
Thats scaring me. Because the current state of the
Andres,
Crossing this over to pgsql-advocacy, because this is really an Advocacy
discussion.
The point is that
a) refreshing is the only way to update materialized views. There's no
incremental support.
b) refreshing will take a long time (otherwise you wouldn't have
create a
On Fri, Mar 8, 2013 at 11:59 AM, Josh Berkus j...@agliodbs.com wrote:
Andres,
Crossing this over to pgsql-advocacy, because this is really an Advocacy
discussion.
The point is that
a) refreshing is the only way to update materialized views. There's no
incremental support.
b) refreshing
On 03/08/2013 10:09 AM, Merlin Moncure wrote:
On Fri, Mar 8, 2013 at 11:59 AM, Josh Berkus j...@agliodbs.com wrote:
Andres,
Further, we get pretty much one and only one chance to promote a new
major feature, which is when that feature is first introduced.
Improving the feature in the next
Andres Freund and...@2ndquadrant.com wrote:
if I understand things correctly REFRESH MATERIALIZED VIEW locks
the materialized view with an AcessExclusiveLock even if the view
already contains data.
Yeah. At the time I had to make a decision on that, REINDEX
CONCURRENTLY did not seem reliable
On 2013-03-07 09:55:39 -0800, Kevin Grittner wrote:
Andres Freund and...@2ndquadrant.com wrote:
if I understand things correctly REFRESH MATERIALIZED VIEW locks
the materialized view with an AcessExclusiveLock even if the view
already contains data.
Yeah. At the time I had to make a
Kevin Grittner kgri...@ymail.com schrieb:
Andres Freund and...@2ndquadrant.com wrote:
if I understand things correctly REFRESH MATERIALIZED VIEW locks
the materialized view with an AcessExclusiveLock even if the view
already contains data.
Yeah. At the time I had to make a decision on
anara...@anarazel.de and...@anarazel.de wrote:
In the ride home I realized that unless - not that unlikely - you
thought about something I didtn't REFRESH will behave similar to
TRUNCATE for repeatable read+ transactions that only access it
after REFRESH finished. That is, they will appear
On 2013-03-07 11:50:11 -0800, Kevin Grittner wrote:
anara...@anarazel.de and...@anarazel.de wrote:
In the ride home I realized that unless - not that unlikely - you
thought about something I didtn't REFRESH will behave similar to
TRUNCATE for repeatable read+ transactions that only
Andres,
if I understand things correctly REFRESH MATERIALIZED VIEW locks the
materialized view with an AcessExclusiveLock even if the view already
contains data.
I am pretty sure that will - understandably - confuse users, so I vote
for at least including a note about that in the docs.
+1
Hi,
On 2013-03-07 15:21:35 -0800, Josh Berkus wrote:
This fact imo reduces the usability of the matviews features as it
stands atm considerably. I think we should be very careful not to
advocate its existance much and document very clearly that its work in
progress.
Working
Postgres is currently full of fairly innocent-looking commands which
take an unexpected ACCESS EXCLUSIVE lock. For example, DROP CONSTRAINT
takes an accessexclusive lock, but it hasn't stopped people from using
constraints, and isn't particularly high up on our todo list to fix
it.
Thats
On 2013-03-07 15:54:32 -0800, Josh Berkus wrote:
Postgres is currently full of fairly innocent-looking commands which
take an unexpected ACCESS EXCLUSIVE lock. For example, DROP CONSTRAINT
takes an accessexclusive lock, but it hasn't stopped people from using
constraints, and isn't
13 matches
Mail list logo
