On Thu, Mar 21, 2019 at 03:41:08PM -0400, Robert Haas wrote:
> Yeah. The fact that a concurrent refresh currently does DELETE+INSERT
> rather than UPDATE is currently an implementation detail. If you
> allow users to hook up triggers to the inserts, then suddenly it's no
> longer an implementatio
On Fri, Jan 4, 2019 at 6:23 AM Peter Eisentraut
wrote:
> What bothers me about this patch is that it subtly changes what a
> trigger means. It currently means, say, INSERT was executed on this
> table. You are expanding that to mean, a row was inserted into this
> table -- somehow.
Yeah. The f
On Tue, Dec 25, 2018 at 10:05 PM Alvaro Herrera
wrote:
> Well, REFRESH CONCURRENTLY runs completely different than non-concurrent
> REFRESH. The former updates the existing data by observing the
> differences with the previous data; the latter simply re-runs the query
> and overwrites everything.
On 3/15/19 8:15 PM, Mitar wrote:
The only pending/unaddressed comment is about the philosophical
question of what it means to be a trigger. There it seems we simply
disagree with the reviewer and I do not know how to address that. I
just see this as a very pragmatical feature which provides feat
Hi!
On Fri, Mar 15, 2019 at 2:46 AM David Steele wrote:
> The reason is that you have not gotten any committer support for this
> patch or attracted significant review, that I can see. On the contrary,
> three committers have expressed doubts about all or some of the patch
> and it doesn't seem
On 3/14/19 12:05 PM, Mitar wrote:
Hi!
On Thu, Mar 7, 2019 at 12:13 AM David Steele wrote:
There doesn't seem to be consensus on whether or not we want this patch.
Peter has issues with the way it works and Andres [1] thinks it should
be pushed to PG13 or possibly rejected.
I'll push this to P
Hi!
On Thu, Mar 7, 2019 at 12:13 AM David Steele wrote:
> There doesn't seem to be consensus on whether or not we want this patch.
> Peter has issues with the way it works and Andres [1] thinks it should
> be pushed to PG13 or possibly rejected.
>
> I'll push this to PG13 for now.
Sorry, I am ne
On 1/5/19 11:57 PM, Mitar wrote:
Having better updating of materialized views using incremental
approach would really benefit my use case as well. Then triggers being
added through my patch here on materialized view itself could
communicate those changes which were done to the client. If I
under
Hi!
On Sat, Jan 5, 2019 at 2:53 AM Nguyễn Trần Quốc Vinh
wrote:
> You can try https://github.com/ntqvinh/PgMvIncrementalUpdate to generate
> triggers in C for incremental updates of matviews.
>
> For asynchronous updates, the tool does generate the triggers for collecting
> updated/inserted/del
Dear,
You can try https://github.com/ntqvinh/PgMvIncrementalUpdate to generate
triggers in C for incremental updates of matviews.
For asynchronous updates, the tool does generate the triggers for
collecting updated/inserted/deleted rows and then the codes for doing
incremental updating as well.
Hi!
I am new to contributing to PostgreSQL and this is my first time
having patches in commit fest, so I am not sure about details of the
process here, but I assume that replying and discuss the patch during
this period is one of the actives, so I am replying to the comment. If
I should wait or so
On 28/12/2018 08:43, Mitar wrote:
> A summary of the patch: This patch enables adding AFTER triggers (both
> ROW and STATEMENT) on materialized views. They are fired when doing
> REFRESH MATERIALIZED VIEW CONCURRENTLY for rows which have changed.
What bothers me about this patch is that it subtly
Hi!
False alarm. It just looks like updating patches takes longer than
updating e-mails.
Mitar
On Fri, Dec 28, 2018 at 12:11 AM Mitar wrote:
>
> Hi!
>
> Hm, why in commitfest it does not display the latest patch?
>
> https://commitfest.postgresql.org/21/1953/
>
> It does display correctly the
Hi!
Hm, why in commitfest it does not display the latest patch?
https://commitfest.postgresql.org/21/1953/
It does display correctly the latest e-mail, but not the link to the patch. :-(
Mitar
On Thu, Dec 27, 2018 at 11:51 PM Mitar wrote:
>
> Hi!
>
> One more version of the patch with slight
Hi!
One more version of the patch with slightly more deterministic tests.
Mitar
On Thu, Dec 27, 2018 at 11:43 PM Mitar wrote:
>
> Hi!
>
> I have made an updated version of the patch, added tests and
> documentation changes. This is my view now a complete patch. Please
> provide any feedback or
Hi!
I have made an updated version of the patch, added tests and
documentation changes. This is my view now a complete patch. Please
provide any feedback or comments you might have for me to improve the
patch. I will also add it to commitfest.
A summary of the patch: This patch enables adding AFT
Hi!
On Wed, Dec 26, 2018 at 4:38 AM Alvaro Herrera wrote:
> Sounds like you could do this by fixing concurrent refresh to also work
> when the MV is WITH NO DATA.
Yes, I do not think this would be too hard to fix. I could do this nevertheless.
> > Ah, yes. I could just do TRUNCATE and INSERT, i
On 2018-Dec-25, Mitar wrote:
> On Tue, Dec 25, 2018 at 7:05 PM Alvaro Herrera
> wrote:
> > But then I'm not clear *why* you would like to do a non-concurrent
> > refresh.
>
> I mostly wanted to support if for two reasons:
>
> - completeness: maybe we cannot imagine the use case yet, but somebo
Hi!
I did a bit of benchmarking. It seems my version with UPDATE takes
even slightly less time (~5%).
Mitar
On Mon, Dec 24, 2018 at 6:17 PM Mitar wrote:
>
> Hi!
>
> I made another version of the patch. This one does UPDATEs for changed
> row instead of DELETE/INSERT.
>
> All existing regressio
Hi!
On Tue, Dec 25, 2018 at 7:05 PM Alvaro Herrera wrote:
> But then I'm not clear *why* you would like to do a non-concurrent
> refresh.
I mostly wanted to support if for two reasons:
- completeness: maybe we cannot imagine the use case yet, but somebody
might in the future
- getting trigger c
On 2018-Dec-25, Mitar wrote:
> On Tue, Dec 25, 2018 at 6:47 PM Alvaro Herrera
> wrote:
> > > I made another version of the patch. This one does UPDATEs for changed
> > > row instead of DELETE/INSERT.
> > >
> > > All existing regression tests are still passing (make check).
> >
> > Okay, but you
Hi!
On Tue, Dec 25, 2018 at 6:47 PM Alvaro Herrera wrote:
> > I made another version of the patch. This one does UPDATEs for changed
> > row instead of DELETE/INSERT.
> >
> > All existing regression tests are still passing (make check).
>
> Okay, but you don't add any for your new feature, which
On 2018-Dec-24, Mitar wrote:
> I made another version of the patch. This one does UPDATEs for changed
> row instead of DELETE/INSERT.
>
> All existing regression tests are still passing (make check).
Okay, but you don't add any for your new feature, which is not good.
--
Álvaro Herrera
Hi!
On Tue, Dec 25, 2018 at 10:03 AM David Fetter wrote:
> If it helps you think about it better, all NOTIFICATIONs are sent on
> COMMIT, i.e. you don't need to worry as much about what things should
> or shouldn't have arrived. The down side, such as it is, is that they
> don't convey premature
On Mon, Dec 24, 2018 at 04:13:44PM -0800, Mitar wrote:
> Hi!
>
> Thanks for reply!
>
> On Mon, Dec 24, 2018 at 2:20 PM David Fetter wrote:
> > You've got the right mailing list, a description of what you want, and
> > a PoC patch. You also got the patch in during the time between
> > Commitfests
Hi!
So I think this makes it work great for REFRESH MATERIALIZED VIEW
CONCURRENTLY. I think we can leave empty statement triggers as they
are. I have not found a nice way to not do them.
For adding triggers to REFRESH MATERIALIZED VIEW I would need some
help and pointers. I am not sure how to wri
Hi!
I made another version of the patch. This one does UPDATEs for changed
row instead of DELETE/INSERT.
All existing regression tests are still passing (make check).
Mitar
On Mon, Dec 24, 2018 at 4:13 PM Mitar wrote:
>
> Hi!
>
> Thanks for reply!
>
> On Mon, Dec 24, 2018 at 2:20 PM David Fet
Hi!
Thanks for reply!
On Mon, Dec 24, 2018 at 2:20 PM David Fetter wrote:
> You've got the right mailing list, a description of what you want, and
> a PoC patch. You also got the patch in during the time between
> Commitfests. You're doing great!
Great!
One thing I am unclear about is how it i
On Mon, Dec 24, 2018 at 12:59:43PM -0800, Mitar wrote:
> Hi!
>
> Based on discussion about observing changes on an open query in a
> reactive manner (to support reactive web applications) [1], I
> identified that one critical feature is missing to fully implement
> discussed design of having react
Hi!
Based on discussion about observing changes on an open query in a
reactive manner (to support reactive web applications) [1], I
identified that one critical feature is missing to fully implement
discussed design of having reactive queries be represented as
materialized views, and changes to th
30 matches
Mail list logo
