On Fri, Sep 09, 2022 at 08:10:32PM +0900, Yugo NAGATA wrote:
> I am working on above issues (#1-#4) now, and I'll respond on each later.
Okay, well. There has been some feedback sent lately and no update
for one month, so I am marking it as RwF for now. As a whole the
patch has been around for
Hello huyajun,
I'm sorry for delay in my response.
On Tue, 26 Jul 2022 12:00:26 +0800
huyajun wrote:
> I read your patch and think this processing is greet, but there is a risk of
> deadlock.
> Although I have not thought of a suitable processing method for the time
> being,
> it is also
Hi, Nagata-san
Thank you for your answer, I agree with your opinion, and found some new
problems to discuss with you
>
>> 3. Consider truncate base tables, IVM will not refresh, maybe raise an error
>> will be better
>
> I fixed to support TRUNCATE on base tables in our repository.
>
Hi huyajun,
Thank you for your comments!
On Wed, 29 Jun 2022 17:56:39 +0800
huyajun wrote:
> Hi, Nagata-san
> I read your patch with v27 version and has some new comments,I want to
> discuss with you.
>
> 1. How about use DEPENDENCY_INTERNAL instead of DEPENDENCY_AUTO
> when record
> 2022年4月22日 下午1:58，Yugo NAGATA 写道：
>
> On Fri, 22 Apr 2022 11:29:39 +0900
> Yugo NAGATA wrote:
>
>> Hi,
>>
>> On Fri, 1 Apr 2022 11:09:16 -0400
>> Greg Stark wrote:
>>
>>> This patch has bitrotted due to some other patch affecting trigger.c.
>>>
>>> Could you post a rebase?
>>>
>>> This
Hello Greg,
On Sat, 23 Apr 2022 08:18:01 +0200
Greg Stark wrote:
> I'm trying to figure out how to get this feature more attention. Everyone
> agrees it would be a huge help but it's a scary patch to review.
>
> I wonder if it would be helpful to have a kind of "readers guide"
> explanation of
I'm trying to figure out how to get this feature more attention. Everyone
agrees it would be a huge help but it's a scary patch to review.
I wonder if it would be helpful to have a kind of "readers guide"
explanation of the patches to help a reviewer understand what the point of
each patch is and
This patch has bitrotted due to some other patch affecting trigger.c.
Could you post a rebase?
This is the last week of the CF before feature freeze so time is of the essence.
Hello Zhihong Yu,
I already replied to your comments before, but I forgot to include
the list to CC, so I resend the same again. Sorry for the duplicate
emails.
On Thu, 3 Feb 2022 09:51:52 -0800
Zhihong Yu wrote:
> For CreateIndexOnIMMV():
>
> + ereport(NOTICE,
> +
On Wed, 16 Feb 2022 22:34:18 +0800
huyajun wrote:
> Hi, Nagata-san
> I am very interested in IMMV and read your patch but have some comments in
> v25-0007-Add-Incremental-View-Maintenance-support.patch and want to discuss
> with you.
Thank you for your review!
>
> + /* For IMMV,
Hi, Nagata-san
I am very interested in IMMV and read your patch but have some comments in
v25-0007-Add-Incremental-View-Maintenance-support.patch and want to discuss
with you.
+ /* For IMMV, we need to rewrite matview query */
+ query = rewriteQueryForIMMV(query,
On Thu, Feb 3, 2022 at 8:50 AM Yugo NAGATA wrote:
> On Thu, 3 Feb 2022 08:48:00 -0800
> Zhihong Yu wrote:
>
> > On Thu, Feb 3, 2022 at 8:28 AM Yugo NAGATA wrote:
> >
> > > Hi,
> > >
> > > On Thu, 13 Jan 2022 18:23:42 +0800
> > > Julien Rouhaud wrote:
> > >
> > > > Hi,
> > > >
> > > > On Thu,
On Thu, Feb 3, 2022 at 8:28 AM Yugo NAGATA wrote:
> Hi,
>
> On Thu, 13 Jan 2022 18:23:42 +0800
> Julien Rouhaud wrote:
>
> > Hi,
> >
> > On Thu, Nov 25, 2021 at 04:37:10PM +0900, Yugo NAGATA wrote:
> > > On Wed, 24 Nov 2021 04:31:25 +
> > > "r.takahash...@fujitsu.com" wrote:
> > >
> > > >
Hi,
On Thu, 13 Jan 2022 18:23:42 +0800
Julien Rouhaud wrote:
> Hi,
>
> On Thu, Nov 25, 2021 at 04:37:10PM +0900, Yugo NAGATA wrote:
> > On Wed, 24 Nov 2021 04:31:25 +
> > "r.takahash...@fujitsu.com" wrote:
> >
> > >
> > > I checked the same procedure on v24 patch.
> > > But following
Hi,
On Thu, Nov 25, 2021 at 04:37:10PM +0900, Yugo NAGATA wrote:
> On Wed, 24 Nov 2021 04:31:25 +
> "r.takahash...@fujitsu.com" wrote:
>
> >
> > I checked the same procedure on v24 patch.
> > But following error occurs instead of the original error.
> >
> > ERROR: relation "ivm_t_index"
Hi hackers,
This is a response to a comment in "Commitfest 2021-11 Patch Triage - Part 1"
[1].
> 2138: Incremental Materialized View Maintenance
> ===
> There seems to be concensus on the thread that this is a feature that we want,
> and after initial
On Wed, 24 Nov 2021 04:31:25 +
"r.takahash...@fujitsu.com" wrote:
> > > ivm=# create table t (c1 int, c2 int);
> > > CREATE TABLE
> > > ivm=# create incremental materialized view ivm_t as select distinct c1
> > > from t;
> > > NOTICE: created index "ivm_t_index" on materialized view
Hello Takahashi-san,
On Wed, 24 Nov 2021 04:27:13 +
"r.takahash...@fujitsu.com" wrote:
> Hi Nagata-san,
>
>
> Sorry for late reply.
>
>
> > However, even if we create triggers recursively on the parents or children,
> > we would still
> > need more consideration. This is because we
Hi Nagata-san,
> Ok. I'll fix _copyIntoClause() and _equalIntoClause() as well as
> _readIntoClause()
> and _outIntoClause().
OK.
> > ivm=# create table t (c1 int, c2 int);
> > CREATE TABLE
> > ivm=# create incremental materialized view ivm_t as select distinct c1 from
> > t;
> > NOTICE:
Hi Nagata-san,
Sorry for late reply.
> However, even if we create triggers recursively on the parents or children,
> we would still
> need more consideration. This is because we will have to convert the format
> of tuple of
> modified table to the format of the table specified in the view
Hello Takahashi-san,
On Wed, 22 Sep 2021 18:53:43 +0900
Yugo NAGATA wrote:
> Hello Takahashi-san,
>
> On Thu, 5 Aug 2021 08:53:47 +
> "r.takahash...@fujitsu.com" wrote:
>
> > Hi Nagata-san,
> >
> >
> > Thank you for your reply.
> >
> > > I'll investigate this more, but we may have to
Hi hackers,
I attached the updated patch including fixes reported by
Zhihong Yu and Ryohei Takahashi.
Regards,
Yugo Nagata
On Wed, 22 Sep 2021 19:12:27 +0900
Yugo NAGATA wrote:
> Hello Takahashi-san,
>
> On Mon, 6 Sep 2021 10:06:37 +
> "r.takahash...@fujitsu.com" wrote:
>
> > Hi
Hello Takahashi-san,
On Mon, 6 Sep 2021 10:06:37 +
"r.takahash...@fujitsu.com" wrote:
> Hi Nagata-san,
>
>
> I'm still reading the patch.
> I have additional comments.
Thank you for your comments!
>
> (1)
> In v23-0001-Add-a-syntax-to-create-Incrementally-Maintainabl.patch, ivm
>
Hello Takahashi-san,
On Thu, 5 Aug 2021 08:53:47 +
"r.takahash...@fujitsu.com" wrote:
> Hi Nagata-san,
>
>
> Thank you for your reply.
>
> > I'll investigate this more, but we may have to prohibit views on partitioned
> > table and partitions.
>
> I think this restriction is strict.
>
Hello Zhihong Yu,
Thank you for your suggestion!
I am sorry for late replay. I'll fix them and submit the
updated patch soon.
On Sat, 7 Aug 2021 00:52:24 -0700
Zhihong Yu wrote:
> > Hi,
> > For v23-0007-Add-Incremental-View-Maintenance-support.patch :
> >
> > bq. In this implementation, AFTER
Hi Nagata-san,
I'm still reading the patch.
I have additional comments.
(1)
In v23-0001-Add-a-syntax-to-create-Incrementally-Maintainabl.patch, ivm member
is added to IntoClause struct.
I think it is necessary to modify _copyIntoClause() and _equalIntoClause()
functions.
(2)
By executing
On Sat, Aug 7, 2021 at 12:00 AM Zhihong Yu wrote:
>
>
> On Sun, Aug 1, 2021 at 11:30 PM Yugo NAGATA wrote:
>
>> Hi hackers,
>>
>> On Mon, 19 Jul 2021 09:24:30 +0900
>> Yugo NAGATA wrote:
>>
>> > On Wed, 14 Jul 2021 21:22:37 +0530
>> > vignesh C wrote:
>>
>> > > The patch does not apply on
On Sun, Aug 1, 2021 at 11:30 PM Yugo NAGATA wrote:
> Hi hackers,
>
> On Mon, 19 Jul 2021 09:24:30 +0900
> Yugo NAGATA wrote:
>
> > On Wed, 14 Jul 2021 21:22:37 +0530
> > vignesh C wrote:
>
> > > The patch does not apply on Head anymore, could you rebase and post a
> > > patch. I'm changing the
Hi Nagata-san,
Thank you for your reply.
> I'll investigate this more, but we may have to prohibit views on partitioned
> table and partitions.
I think this restriction is strict.
This feature is useful when the base table is large and partitioning is also
useful in such case.
I have
Hello Takahashi-san,
On Tue, 3 Aug 2021 10:15:42 +
"r.takahash...@fujitsu.com" wrote:
> Hi Nagata-san,
>
>
> I am interested in this patch since it is good feature.
>
> I run some simple tests.
> I found the following problems.
Thank you for your interest for this patch!
> (1)
>
Hello Zhihong Yu,
On Mon, 2 Aug 2021 14:33:46 -0700
Zhihong Yu wrote:
> On Sun, Aug 1, 2021 at 11:30 PM Yugo NAGATA wrote:
>
> > Hi hackers,
> >
> > On Mon, 19 Jul 2021 09:24:30 +0900
> > Yugo NAGATA wrote:
> >
> > > On Wed, 14 Jul 2021 21:22:37 +0530
> > > vignesh C wrote:
> >
> > > > The
Hi Nagata-san,
I am interested in this patch since it is good feature.
I run some simple tests.
I found the following problems.
(1)
Failed to "make world".
I think there are extra "" in
doc/src/sgml/ref/create_materialized_view.sgml
(line 110 and 117)
(2)
In the case of partition, it
On Sun, Aug 1, 2021 at 11:30 PM Yugo NAGATA wrote:
> Hi hackers,
>
> On Mon, 19 Jul 2021 09:24:30 +0900
> Yugo NAGATA wrote:
>
> > On Wed, 14 Jul 2021 21:22:37 +0530
> > vignesh C wrote:
>
> > > The patch does not apply on Head anymore, could you rebase and post a
> > > patch. I'm changing the
On Wed, 14 Jul 2021 21:22:37 +0530
vignesh C wrote:
> On Mon, May 17, 2021 at 10:08 AM Yugo NAGATA wrote:
> >
> > On Fri, 7 May 2021 14:14:16 +0900
> > Yugo NAGATA wrote:
> >
> > > On Mon, 26 Apr 2021 16:03:48 +0900
> > > Yugo NAGATA wrote:
> > >
> > > > On Mon, 26 Apr 2021 15:46:21 +0900
> >
On Mon, May 17, 2021 at 10:08 AM Yugo NAGATA wrote:
>
> On Fri, 7 May 2021 14:14:16 +0900
> Yugo NAGATA wrote:
>
> > On Mon, 26 Apr 2021 16:03:48 +0900
> > Yugo NAGATA wrote:
> >
> > > On Mon, 26 Apr 2021 15:46:21 +0900
> > > Yugo NAGATA wrote:
> > >
> > > > On Tue, 20 Apr 2021 09:51:34 +0900
On Fri, 7 May 2021 14:14:16 +0900
Yugo NAGATA wrote:
> On Mon, 26 Apr 2021 16:03:48 +0900
> Yugo NAGATA wrote:
>
> > On Mon, 26 Apr 2021 15:46:21 +0900
> > Yugo NAGATA wrote:
> >
> > > On Tue, 20 Apr 2021 09:51:34 +0900
> > > Yugo NAGATA wrote:
> > >
> > > > On Mon, 19 Apr 2021 17:40:31
On Mon, 26 Apr 2021 16:03:48 +0900
Yugo NAGATA wrote:
> On Mon, 26 Apr 2021 15:46:21 +0900
> Yugo NAGATA wrote:
>
> > On Tue, 20 Apr 2021 09:51:34 +0900
> > Yugo NAGATA wrote:
> >
> > > On Mon, 19 Apr 2021 17:40:31 -0400
> > > Tom Lane wrote:
> > >
> > > > Andrew Dunstan writes:
> > > > >
On Mon, 26 Apr 2021 15:46:21 +0900
Yugo NAGATA wrote:
> On Tue, 20 Apr 2021 09:51:34 +0900
> Yugo NAGATA wrote:
>
> > On Mon, 19 Apr 2021 17:40:31 -0400
> > Tom Lane wrote:
> >
> > > Andrew Dunstan writes:
> > > > This patch (v22c) just crashed for me with an assertion failure on
> > > >
On Tue, 20 Apr 2021 09:51:34 +0900
Yugo NAGATA wrote:
> On Mon, 19 Apr 2021 17:40:31 -0400
> Tom Lane wrote:
>
> > Andrew Dunstan writes:
> > > This patch (v22c) just crashed for me with an assertion failure on
> > > Fedora 31. Here's the stack trace:
> >
> > > #2 0x0094a54a in
On Mon, 19 Apr 2021 17:40:31 -0400
Tom Lane wrote:
> Andrew Dunstan writes:
> > This patch (v22c) just crashed for me with an assertion failure on
> > Fedora 31. Here's the stack trace:
>
> > #2 0x0094a54a in ExceptionalCondition
> > (conditionName=conditionName@entry=0xa91dae
Andrew Dunstan writes:
> This patch (v22c) just crashed for me with an assertion failure on
> Fedora 31. Here's the stack trace:
> #2 0x0094a54a in ExceptionalCondition
> (conditionName=conditionName@entry=0xa91dae "queryDesc->sourceText !=
> NULL", errorType=errorType@entry=0x99b468
On 4/7/21 5:25 AM, Yugo NAGATA wrote:
> Hi,
>
> I rebased the patch because the cfbot failed.
>
> Regards,
> Yugo Nagata
This patch (v22c) just crashed for me with an assertion failure on
Fedora 31. Here's the stack trace:
[New LWP 333090]
[Thread debugging using libthread_db enabled]
Hi,
I rebased the patch because the cfbot failed.
Regards,
Yugo Nagata
On Tue, 9 Mar 2021 17:27:50 +0900
Yugo NAGATA wrote:
> On Tue, 9 Mar 2021 09:20:49 +0900
> Yugo NAGATA wrote:
>
> > On Mon, 8 Mar 2021 15:42:00 -0500
> > Andrew Dunstan wrote:
> >
> > >
> > > On 2/18/21 9:01 PM, Yugo
On Tue, 9 Mar 2021 09:20:49 +0900
Yugo NAGATA wrote:
> On Mon, 8 Mar 2021 15:42:00 -0500
> Andrew Dunstan wrote:
>
> >
> > On 2/18/21 9:01 PM, Yugo NAGATA wrote:
> > > On Thu, 18 Feb 2021 19:38:44 +0800
> > > Andy Fan wrote:
> > >
> > >> On Tue, Feb 16, 2021 at 9:33 AM Yugo NAGATA wrote:
>
From: Thomas Munro
> It's probably time to move forward with the plan of pushing the
> results into a commitfest.postgresql.org API, and then making Magnus
> et al write the email spam code with a preferences screen linked to
> your community account :-D
+1
I wish to see all the patch status
On Tue, Mar 9, 2021 at 1:22 PM Yugo NAGATA wrote:
> On Mon, 8 Mar 2021 15:42:00 -0500
> Andrew Dunstan wrote:
> > (A useful feature of the cfbot might be to notify the authors and
> > reviewers when it detects bitrot for a previously passing entry.)
>
> +1
> The feature notifying it authors
On Mon, 8 Mar 2021 15:42:00 -0500
Andrew Dunstan wrote:
>
> On 2/18/21 9:01 PM, Yugo NAGATA wrote:
> > On Thu, 18 Feb 2021 19:38:44 +0800
> > Andy Fan wrote:
> >
> >> On Tue, Feb 16, 2021 at 9:33 AM Yugo NAGATA wrote:
> >>
> >>> Hi,
> >>>
> >>> Attached is a rebased patch (v22a).
> >>>
> >>
On 2/18/21 9:01 PM, Yugo NAGATA wrote:
> On Thu, 18 Feb 2021 19:38:44 +0800
> Andy Fan wrote:
>
>> On Tue, Feb 16, 2021 at 9:33 AM Yugo NAGATA wrote:
>>
>>> Hi,
>>>
>>> Attached is a rebased patch (v22a).
>>>
>> Thanks for the patch. Will you think posting a patch with the latest commit
>> at
On Thu, 18 Feb 2021 19:38:44 +0800
Andy Fan wrote:
> On Tue, Feb 16, 2021 at 9:33 AM Yugo NAGATA wrote:
>
> > Hi,
> >
> > Attached is a rebased patch (v22a).
> >
>
> Thanks for the patch. Will you think posting a patch with the latest commit
> at that
> time is helpful? If so, when others
On Tue, Feb 16, 2021 at 9:33 AM Yugo NAGATA wrote:
> Hi,
>
> Attached is a rebased patch (v22a).
>
Thanks for the patch. Will you think posting a patch with the latest commit
at that
time is helpful? If so, when others want to review it, they know which
commit to
apply the patch without asking
Hi,
Attached is a rebased patch (v22a).
Ragards,
Yugo Nagata
--
Yugo NAGATA
IVM_patches_v22a.tar.gz
Description: application/gzip
Hi,
Attached is a revised patch (v22) rebased for the latest master head.
Regards,
Yugo Nagata
--
Yugo NAGATA
IVM_patches_v22.tar.gz
Description: application/gzip
Hi,
Attached is the revised patch (v21) to add support for Incremental
Materialized View Maintenance (IVM).
In addition to some typos in the previous enhancement, I fixed a check to
prevent a view from containing an expression including aggregates like
sum(x)/sum(y) in this revision.
Regards,
Hi Yugo,
> 1. Creating an index on the matview automatically
Nice.
> 2. Use a weaker lock on the matview if possible
>
> If the view has only one base table in this query, RowExclusiveLock is
> held on the view instead of AccessExclusiveLock, because we don't
> need to wait other concurrent
Hi hackers,
I heard the opinion that this patch is too big and hard to review.
So, I wander that we should downsize the patch by eliminating some
features and leaving other basic features.
If there are more opinions this makes it easer for reviewers to look
at this patch, I would like do it. If
Hi,
Attached is the revised patch (v20) to add support for Incremental
Materialized View Maintenance (IVM).
In according with Konstantin's suggestion, I made a few optimizations.
1. Creating an index on the matview automatically
When creating incremental maintainable materialized view (IMMV)s,
On Wed, 25 Nov 2020 18:00:16 +0300
Konstantin Knizhnik wrote:
>
>
> On 25.11.2020 16:06, Yugo NAGATA wrote:
> > On Wed, 25 Nov 2020 15:16:05 +0300
> > Konstantin Knizhnik wrote:
> >
> >>
> >> On 24.11.2020 13:11, Yugo NAGATA wrote:
> I wonder if it is possible to somehow use predicate
On 25.11.2020 16:06, Yugo NAGATA wrote:
On Wed, 25 Nov 2020 15:16:05 +0300
Konstantin Knizhnik wrote:
On 24.11.2020 13:11, Yugo NAGATA wrote:
I wonder if it is possible to somehow use predicate locking mechanism of
Postgres to avoid this anomalies without global lock?
You mean that,
On Wed, 25 Nov 2020 15:16:05 +0300
Konstantin Knizhnik wrote:
>
>
> On 24.11.2020 13:11, Yugo NAGATA wrote:
> >
> >> I wonder if it is possible to somehow use predicate locking mechanism of
> >> Postgres to avoid this anomalies without global lock?
> > You mean that, ,instead of using any
On 24.11.2020 13:11, Yugo NAGATA wrote:
I wonder if it is possible to somehow use predicate locking mechanism of
Postgres to avoid this anomalies without global lock?
You mean that, ,instead of using any table lock, if any possibility of the
anomaly is detected using predlock mechanism
On Tue, 24 Nov 2020 12:46:57 +0300
Konstantin Knizhnik wrote:
>
>
> On 24.11.2020 12:21, Yugo NAGATA wrote:
> >
> >> I replaced it with RowExlusiveLock and ... got 1437 TPS with 10
> >> connections.
> >> It is still about 7 times slower than performance without incremental view.
> >> But now
On 24.11.2020 12:21, Yugo NAGATA wrote:
I replaced it with RowExlusiveLock and ... got 1437 TPS with 10 connections.
It is still about 7 times slower than performance without incremental view.
But now the gap is not so dramatic. And it seems to be clear that this
exclusive lock on matview
On Thu, 12 Nov 2020 15:37:42 +0300
Konstantin Knizhnik wrote:
> Well, creation of proper indexes for table is certainly responsibility
> of DBA.
> But users may not consider materialized view as normal table. So the
> idea that index should
> be explicitly created for materialized view seems
On Wed, 11 Nov 2020 19:10:35 +0300
Konstantin Knizhnik wrote:
Thank you for reviewing this patch!
>
> The patch is not applied to the current master because makeFuncCall
> prototype is changed,
> I fixed it by adding COAERCE_CALL_EXPLICIT.
The rebased patch was submitted.
> Ooops! Now TPS
> 1. Create pgbench database with scale 100.
> pgbench speed at my desktop is about 10k TPS:
>
> pgbench -M prepared -N -c 10 -j 4 -T 30 -P 1 postgres
> tps = 10194.951827 (including connections establishing)
>
> 2. Then I created incremental materialized view:
>
> create incremental
On Thu, 5 Nov 2020 22:58:25 -0600
Justin Pryzby wrote:
> On Mon, Oct 05, 2020 at 06:16:18PM +0900, Yugo NAGATA wrote:
> This needs to be rebased again - the last version doesn't apply anymore.
> http://cfbot.cputube.org/yugo-nagata.html
I attached the rebased patch (v19).
> I looked though it
Hello Konstantin,
I remember testing it with pg_stat_statements (and planning counters
enabled). Maybe identifying internal queries associated with this (simple)
test case, could help dev team ?
Regards
PAscal
--
Sent from: https://www.postgresql-archive.org/PostgreSQL-hackers-f1928748.html
On 05.10.2020 12:16, Yugo NAGATA wrote:
Hi,
Attached is the rebased patch (v18) to add support for Incremental
Materialized View Maintenance (IVM). It is able to be applied to
current latest master branch.
Thank you very much for this work.
I consider incremental materialized views as
On Mon, Oct 05, 2020 at 06:16:18PM +0900, Yugo NAGATA wrote:
> Hi,
>
> Attached is the rebased patch (v18) to add support for Incremental
This needs to be rebased again - the last version doesn't apply anymore.
http://cfbot.cputube.org/yugo-nagata.html
I looked though it a bit and attach some
On Wed, 28 Oct 2020 12:01:58 +0300
Anastasia Lubennikova wrote:
> ср, 28 окт. 2020 г. в 08:02, Yugo NAGATA :
>
> > Hi Anastasia Lubennikova,
> >
> > I am writing this to you because I would like to ask the commitfest
> > manager something.
> >
> > The status of the patch was changed to "Waiting
ср, 28 окт. 2020 г. в 08:02, Yugo NAGATA :
> Hi Anastasia Lubennikova,
>
> I am writing this to you because I would like to ask the commitfest
> manager something.
>
> The status of the patch was changed to "Waiting on Author" from
> "Ready for Committer" at the beginning of this montfor the
On Tue, 27 Oct 2020 12:14:52 -0400
Adam Brusselback wrote:
> That was a good bit more work to get ready than I expected. It's broken
> into two scripts, one to create the schema, the other to load data and
> containing a couple check queries to ensure things are working properly
> (checking the
Hi Anastasia Lubennikova,
I am writing this to you because I would like to ask the commitfest
manager something.
The status of the patch was changed to "Waiting on Author" from
"Ready for Committer" at the beginning of this montfor the reason
that rebase was necessary. Now I updated the patch,
That was a good bit more work to get ready than I expected. It's broken
into two scripts, one to create the schema, the other to load data and
containing a couple check queries to ensure things are working properly
(checking the materialized tables against a regular view for accuracy).
The first
Hi Adam,
On Thu, 22 Oct 2020 10:07:29 -0400
Adam Brusselback wrote:
> Hey there Yugo,
> I've asked a coworker to prepare a self contained example that encapsulates
> our multiple use cases.
Thank you very much!
> The immediate/eager approach is exactly what we need, as within the same
>
Hey there Yugo,
I've asked a coworker to prepare a self contained example that encapsulates
our multiple use cases.
The immediate/eager approach is exactly what we need, as within the same
transaction we have statements that can cause one of those "materialized
tables" to be updated, and then
Hi Adam Brusselback,
On Mon, 31 Dec 2018 11:20:11 -0500
Adam Brusselback wrote:
> Hi all, just wanted to say I am very happy to see progress made on this,
> my codebase has multiple "materialized tables" which are maintained with
> statement triggers (transition tables) and custom functions.
> * Aggregate support
>
> The current patch supports several built-in aggregates, that is, count, sum,
> avg, min, and max. Other built-in aggregates or user-defined aggregates are
> not supported.
>
> Aggregates in a materialized view definition is checked if this is supported
> using OIDs of
Hi,
I have reviewed the past discussions in this thread on IVM implementation
of the proposed patch[1], and summarized it as following . We would appreciate
any comments or suggestions on the patch as regard of them.
* Aggregate support
The current patch supports several built-in aggregates,
Hi,
Attached is the rebased patch (v18) to add support for Incremental
Materialized View Maintenance (IVM). It is able to be applied to
current latest master branch.
Also, this now supports simple CTEs (WITH clauses) which do not contain
aggregates or DISTINCT like simple sub-queries. This
On Thu, 1 Oct 2020 13:43:49 +0900
Fujii Masao wrote:
> When I glanced the doc patch (i.e., 0012), I found some typos.
Thank you for your pointing out typos! I'll fix it.
>
> +CRATE INCREMENTAL MATERIALIZED VIEW, for example:
>
> Typo: CRATE should be CREATE ?
>
> +with __ivm_ and
On 2020/10/01 13:03, Tatsuo Ishii wrote:
On Thu, Sep 17, 2020 at 09:42:45AM +0900, Tatsuo Ishii wrote:
I am asking because these patch sets are now getting closer to
committable state in my opinion, and if there's someting wrong, it
should be fixed soon so that these patches are getting into
> On Thu, Sep 17, 2020 at 09:42:45AM +0900, Tatsuo Ishii wrote:
>> I am asking because these patch sets are now getting closer to
>> committable state in my opinion, and if there's someting wrong, it
>> should be fixed soon so that these patches are getting into the master
>> branch.
>>
>> I
On Thu, Sep 17, 2020 at 09:42:45AM +0900, Tatsuo Ishii wrote:
> I am asking because these patch sets are now getting closer to
> committable state in my opinion, and if there's someting wrong, it
> should be fixed soon so that these patches are getting into the master
> branch.
>
> I think this
> I have nothing, I'm just reading starter papers and trying to learn a
> bit more about the concepts at this stage. I was thinking of
> reviewing some of the more mechanical parts of the patch set, though,
> like perhaps the transition table lifetime management, since I have
> worked on that
On Wed, 9 Sep 2020 14:22:28 +1200
Thomas Munro wrote:
> > Therefore, usual update semantics (tuple locks and EvalPlanQual) and UPSERT
> > can be used for optimization for some classes of view, but we don't have any
> > other better idea than using table lock for views joining tables. We would
>
On Wed, Sep 9, 2020 at 12:29 PM Yugo NAGATA wrote:
> I also thought it might be resolved using tuple locks and EvalPlanQual
> instead of table level lock, but there is still a unavoidable case. For
> example, suppose that tuple dR is inserted into R in T1, and dS is inserted
> into S in T2.
Hi Thomas,
Thank you for your comment!
On Sat, 5 Sep 2020 17:56:18 +1200
Thomas Munro wrote:
> + /*
> +* Wait for concurrent transactions which update this materialized view at
> +* READ COMMITED. This is needed to see changes committed in other
> +* transactions. No wait and
Hi Nagata-san,
On Mon, Aug 31, 2020 at 5:32 PM Yugo NAGATA wrote:
> https://wiki.postgresql.org/wiki/Incremental_View_Maintenance
Thanks for writing this!
+ /*
+* Wait for concurrent transactions which update this materialized view at
+* READ COMMITED. This is needed to see changes
Hi,
I updated the wiki page.
https://wiki.postgresql.org/wiki/Incremental_View_Maintenance
On Fri, 21 Aug 2020 21:40:50 +0900 (JST)
Tatsuo Ishii wrote:
> From: Yugo NAGATA
> Subject: Re: Implementing Incremental View Maintenance
> Date: Fri, 21 Aug 2020 17:23:20 +0900
>
From: Yugo NAGATA
Subject: Re: Implementing Incremental View Maintenance
Date: Fri, 21 Aug 2020 17:23:20 +0900
Message-ID: <20200821172320.a2506577d5244b6066f69...@sraoss.co.jp>
> On Wed, 19 Aug 2020 10:02:42 +0900 (JST)
> Tatsuo Ishii wrote:
>
>> I have looked into
On Wed, 19 Aug 2020 10:02:42 +0900 (JST)
Tatsuo Ishii wrote:
> I have looked into this.
Thank you for your reviewing!
> - 0004-Allow-to-prolong-life-span-of-transition-tables-unti.patch:
> This one needs a comment to describe what the function does etc.
>
> +void
>
I have looked into this.
> Hi,
>
> Attached is the rebased patch (v16) to add support for Incremental
> Materialized View Maintenance (IVM). It is able to be applied to
> current latest master branch.
>
> This also includes the following small fixes:
>
> - Add a query check for expressions
Hi,
Attached is the rebased patch (v16) to add support for Incremental
Materialized View Maintenance (IVM). It is able to be applied to
current latest master branch.
This also includes the following small fixes:
- Add a query check for expressions containing aggregates in it
- [doc] Add
On Tue, Jul 7, 2020 at 3:26 PM Tatsuo Ishii wrote:
> >> Query checks for following restrictions are added:
> >
> >
> > Are all known supported cases listed below?
>
> They are "restrictions" and are not supported.
>
Yes, I missed the "not" word:(
>
> >> - inheritance parent table
> >> ...
> >>
>> Query checks for following restrictions are added:
>
>
> Are all known supported cases listed below?
They are "restrictions" and are not supported.
>
>> - inheritance parent table
>> ...
>> - targetlist containing IVM column
>> - simple subquery is only supported
>>
>
> How to understand 3
Thanks for the patch!
> Query checks for following restrictions are added:
Are all known supported cases listed below?
> - inheritance parent table
> ...
> - targetlist containing IVM column
> - simple subquery is only supported
>
How to understand 3 items above?
-
Best Regards
Andy Fan
>> +1, This is a smart idea. How did you test it? AFAIK, we can test it
> with:
>
> 1. For any query like SELECT xxx, we create view like CREATE MATERIAL VIEW
> mv_name as SELECT xxx; to test if the features in the query are supported.
No I didn't test the correctness of IVM with TPC-DS
On Fri, May 8, 2020 at 9:13 AM Tatsuo Ishii wrote:
> >> Hi,
> >>
> >> Attached is the latest patch (v15) to add support for Incremental
> Materialized
> >> View Maintenance (IVM). It is possible to apply to current latest
> master branch.
>
> I have tried to use IVM against TPC-DS
>> Hi,
>>
>> Attached is the latest patch (v15) to add support for Incremental
>> Materialized
>> View Maintenance (IVM). It is possible to apply to current latest master
>> branch.
I have tried to use IVM against TPC-DS (http://www.tpc.org/tpcds/)
queries. TPC-DS models decision support
1 - 100 of 215 matches
Mail list logo
