rint some
> messages with 'X %' and others with 'X%'.
I agree with Daniel. If inserting a space in front of % was intentional for
handling the result in such tools, we should fix other places where 'X%' is
used in the pgbench output.
Regards,
Yugo Nagata
--
Yugo NAGATA
ld need to add a new message to signal the start of pipeline mode
to the protocol. It is user responsible to avoid the problematic
protocol use when libpq is not used.
What do you think about it?
Regards,
Yugo Nagata
--
Yugo NAGATA
Hi Horiguchi-san,
On Thu, 27 Jan 2022 17:50:25 +0900 (JST)
Kyotaro Horiguchi wrote:
> At Tue, 16 Nov 2021 02:26:43 +0900, Yugo NAGATA wrote
> in
> > Thank you for pointing it out!
> > I attached the updated patch.
>
> I think we want more elabolative comment for the
y in CreateIndexOnIMMV.
This was also necessary for supporting CTEs, but unnecessary in the current
patch, so I'll fix it, too.
Regards,
Yugo Nagata
--
Yugo NAGATA
February but I have the same
> > difficulty wrapping my head around the amount of info here.
> >
> > Is this one really likely to be commitable in 15? If not I think we
> > should move this to 16 now and concentrate on patches that will be
> > commitable in this release.
I think this patch set needs more reviews to be commitable in 15, so I
returned the target version to blank. I'll change it to 16 later.
> >
> > > 2218: Implement INSERT SET syntax
> > > =
> > > The author has kept this patch updated, and has seemingly updated
> > > according to
> > > the review comments. Tom: do you have any opinions on whether the updated
> > > version addresses your concerns wrt the SELECT rewrite?
> >
> > I don't see any discussion implying that Tom's concerns were met. I'm
> > not exactly clear why Tom's concerns are real problems though --
> > wouldn't it be a *good* thing if we have a more expressive syntax? But
> > that's definitely what needs to be resolved before it can move ahead.
> >
> > So unless there's objections I'm going to update this to "waiting on
> > author".
> >
> > --
> > greg
>
>
>
> --
> greg
--
Yugo NAGATA
w.
> For check_ivm_restriction_walker():
>
> + break;
> + expression_tree_walker(node, check_ivm_restriction_walker,
> NULL);
> + break;
>
> Something is missing between the break and expression_tree_walker().
Yes, it's my mistake during making the p
MATERIALIZED VIEW, so I think it is better to support this in psql
tab-completion and be documented.
I attached a patch to fix the tab-completion and the documentation
about this syntax. Also, I added description about SET TABLESPACE
syntax that would have been overlooked.
Regards,
Yugo Nagata
--
Yugo
Hi Michael-san,
On Wed, 16 Mar 2022 16:18:09 +0900
Michael Paquier wrote:
> Hi Nagata-san,
>
> On Wed, Mar 16, 2022 at 01:33:37PM +0900, Yugo NAGATA wrote:
> > SET ACCESS METHOD is supported in ALTER TABLE since the commit
> > b0483263dd. Since that time, this also has
; separate function and call it.
Ok. I made a new function "discardUntilSync" for the pipeline cleaning.
> I think that the report should not remove data when they are 0, otherwise it
> makes
> it harder to script around it (in failures_detailed on line 6284).
I fixed to report bo
d. In other places
> "link" tag is used instead:
Thank you for pointing out it.
I've checked other places using referring to , and found
that "xreflabel"s are used in such tags. So, I'll fix it
in this style.
Regards,
Yugo Nagata
--
Yugo NAGATA
uot; as well as "cycles". However, I am not sure
that the situation is improved by using such word because what such word
exactly means seems to be still unclear for users.
Another idea is instead reporting only "the number of successfully
retried transactions" that does not include "failed transactions",
that is, transactions failed after retries, like this;
number of transactions actually processed: 100/100
number of failed transactions: 0 (0.000%)
number of successfully retried transactions: 35 (35.000%)
total number of retries: 74
The meaning is clear and there seems to be no confusion.
Regards,
Yugo Nagata
--
Yugo NAGATA
On Tue, 22 Mar 2022 09:08:15 +0900
Yugo NAGATA wrote:
> Hi Ishii-san,
>
> On Sun, 20 Mar 2022 09:52:06 +0900 (JST)
> Tatsuo Ishii wrote:
>
> > Hi Yugo,
> >
> > I have looked into the patch and I noticed that > linkend=... endterm=...> is used in pgbe
ed the
> new entry there, and I have added a test checking after an error for
> multiple subcommands, while on it.
>
> Thanks, Nagata-san!
Thank you!
--
Yugo NAGATA
ges.
I have edited the test code from the original patch by mistake, but
I could not realize because the test works in my machine without any
errors somehow.
I attached a patch to fix the test as was in the original patch, where
backreferences are used to check retry of the same query.
Regards,
Yugo
e that the effect
of the optimization.
Regards,
Yugo Nagata
--
Yugo NAGATA
IVM_patches_v20.tar.gz
Description: application/gzip
so, we plan to support only
selection, projection, inner-join, and some aggregates in the first
release and leave sub-queries, outer-join, and CTE supports to the
next release.
Regards,
Yugo Nagata
On Tue, 22 Dec 2020 21:51:36 +0900
Yugo NAGATA wrote:
> Hi,
>
> Attached is the revi
problem, because even now, if
> > we issue a simple select pg_reload_conf(); (without even changing any
> > config parameter), WakeupRecovery gets called.
> >
> > Thanks for the patch. I tested the new function and it works as
> > expected. I have no further comments on the v13 patch.
>
> Thanks for the review and testing.
I have no futher comments on the v13 patch, too. Also, I agree with
Robert Haas's suggestions.
Regards,
Yugo Nagata
--
Yugo NAGATA
Hi,
Attached is a rebased patch (v22a).
Ragards,
Yugo Nagata
--
Yugo NAGATA
IVM_patches_v22a.tar.gz
Description: application/gzip
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 tha
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:
> >>
> >>
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:
> > >
> >
I updated the patch, so can I change
the status back to "Ready for Committer"?
Regards,
Yugo Nagata
On Mon, 5 Oct 2020 18:16:18 +0900
Yugo NAGATA wrote:
> Hi,
>
> Attached is the rebased patch (v18) to add support for Incremental
> Materialized View Maintenance (IVM). It
e use cases where immediate view maintenance is useful.
I am happy because I found concrete use cases of immediate IVM. However,
unfortunately, the view definitions in your cases are complex, and the current
implementation of the patch doesn't support it. We would like to improve the
featu
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 s
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
modified. Therefore,
this is not suitable to OLTP workload where there are frequent updates of
tables.
For suppressing maintenance overhead in such workload, we have to implement
"deferred maintenance" which collects table change logs and updates the view
in another transaction afterward.
Regards,
Yugo Nagata
--
Yugo NAGATA
es=# refresh materialized view teller_avgs;
> REFRESH MATERIALIZED VIEW
> Time: 55500.381 ms (00:55.500)
Hmm, interesting... I would like to investigate this issue, too.
Regards,
Yugo Nagata
--
Yugo NAGATA
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 performa
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?
> &g
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:
> >>
or false, users can use the old format for calling this
and the backward compatibility can be maintained.
As another comment, while pg_is_wal_replay_paused is blocking, I can not cancel
the query. I think CHECK_FOR_INTERRUPTS() is necessary in the waiting loop.
+ errhint("Recovery control functions can only be executed
during recovery.")));
There are a few tabs at the end of this line.
Regards,
Yugo Nagata
--
Yugo NAGATA
,
Yugo Nagata
On Tue, 22 Dec 2020 22:24:22 +0900
Yugo NAGATA wrote:
> 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 th
paused() can make user wait for a long time, I don't care
either.
> > > As another comment, while pg_is_wal_replay_paused is blocking, I can not
> > > cancel
> > > the query. I think CHECK_FOR_INTERRUPTS() is necessary in the waiting
> > > loop.
How about this fix? I think users may want to cancel pg_is_wal_replay_paused()
during
this is blocking.
Regards,
Yugo Nagata
--
Yugo NAGATA
On Wed, 13 Jan 2021 17:49:43 +0530
Dilip Kumar wrote:
> On Wed, Jan 13, 2021 at 3:35 PM Dilip Kumar wrote:
> >
> > On Wed, Jan 13, 2021 at 3:27 PM Yugo NAGATA wrote:
> > >
> > > On Thu, 10 Dec 2020 11:25:23 +0530
> > > Dilip Kumar wrote:
> > &g
On Sun, 17 Jan 2021 11:33:52 +0530
Dilip Kumar wrote:
> On Thu, Jan 14, 2021 at 6:49 PM Yugo NAGATA wrote:
> >
> > On Wed, 13 Jan 2021 17:49:43 +0530
> > Dilip Kumar wrote:
> >
> > > On Wed, Jan 13, 2021 at 3:35 PM Dilip Kumar wrote:
> > > >
>
iate MCV list, and is it useful?
(10)
To achieve adaptive query optimization (AQO) in PostgreSQL, this patch proposes
to use auto_explain for getting feedback from actual results. So, could
auto_explain
be a infrastructure of AQO in future? Or, do you have any plan or idea to make
built-in infrastructure for AQO?
Regards,
Yugo Nagata
--
Yugo NAGATA
On Tue, 19 Jan 2021 21:32:31 +0530
Dilip Kumar wrote:
> On Tue, Jan 19, 2021 at 8:34 AM Dilip Kumar wrote:
> >
> > On Tue, 19 Jan 2021 at 8:12 AM, Yugo NAGATA wrote:
> >>
> >> On Sun, 17 Jan 2021 11:33:52 +0530
> >> Dilip Kumar wrote:
> >>
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
Here(), but this seems redundant.
(2)
- while (RecoveryIsPaused())
+ while (GetRecoveryPauseState() != RECOVERY_NOT_PAUSED)
{
+
HandleStartupProcInterrupts();
Though it is trivial, I think the new line after the brace is unnecessary.
Regards,
Yugo Nagata
--
Yugo NAGATA
plans seems useful.
> Actually task of adaptive query optimization is much bigger.
> We have separate AQO extension which tries to use machine learning to
> correctly adjust estimations.
> This my patch is much simpler and use existed mechanism (extended
> statistics) to improve estimations.
Well, this patch provide a kind of AQO as auto_explain feature, but this
is independent of the AQO extension. Is it right?
Anyway, I'm interested in the AQO extension, so I'll look into this, too.
Regards,
Yugo Nagata
--
Yugo NAGATA
e name you suggest that returns text.
> > > That would create less burden for tool authors.
> >
> > +1
> >
>
> Yeah, we can do that, I will send an updated patch soon.
This means pg_is_wal_replay_paused is left without any change and this
returns whether pause is requested or not? If so, it seems good to modify
the documentation of this function in order to note that this could not
return the actual pause state.
Regards,
Yugo Nagata
--
Yugo NAGATA
his patch.
diff --git a/src/test/regress/expected/timetz.out
b/src/test/regress/expected/timetz.out
index 038bb5fa094..5294179aa45 100644
Regards,
Yugo Nagata
--
Yugo NAGATA
On Thu, 28 Jan 2021 09:55:42 +0530
Dilip Kumar wrote:
> On Wed, Jan 27, 2021 at 2:28 PM Dilip Kumar wrote:
> >
> > On Wed, Jan 27, 2021 at 2:06 PM Yugo NAGATA wrote:
> > >
> > > On Wed, 27 Jan 2021 13:29:23 +0530
> > > Dilip Kumar wrote:
> > >
On Fri, 29 Jan 2021 16:33:32 +0530
Dilip Kumar wrote:
> On Fri, Jan 29, 2021 at 3:25 PM Yugo NAGATA wrote:
> >
> > On Thu, 28 Jan 2021 09:55:42 +0530
> > Dilip Kumar wrote:
> >
> > > On Wed, Jan 27, 2021 at 2:28 PM Dilip Kumar wrote:
> > > >
>
On Mon, 1 Feb 2021 13:28:45 +0800
Julien Rouhaud wrote:
> On Thu, Jan 28, 2021 at 8:38 PM Yugo NAGATA wrote:
> >
> > postgres=# explain (analyze, verbose) select * from a,b where a.i=b.j;
> >
HandleStartupProcInterrupts();
If a user call pg_wal_replay_pause while waiting in
RecoveryRequiresIntParameter,
the state become 'pause requested' and this never returns to 'paused'.
Should we check recoveryPauseState in this loop as in recoveryPausesHere?
Regards,
Yugo Nagata
--
Yugo NAGATA
On Mon, 8 Feb 2021 07:51:22 +0530
Dilip Kumar wrote:
> On Mon, 8 Feb 2021 at 6:38 AM, Yugo NAGATA wrote:
>
> > Hi,
> >
> > On Sun, 7 Feb 2021 19:27:02 +0530
> > Dilip Kumar wrote:
> >
> > > On Sun, Feb 7, 2021 at 6:44 PM Bharath Rupireddy
> &g
On Mon, 8 Feb 2021 09:35:00 +0530
Dilip Kumar wrote:
> On Mon, Feb 8, 2021 at 8:18 AM Yugo NAGATA wrote:
> >
> > On Mon, 8 Feb 2021 07:51:22 +0530
> > Dilip Kumar wrote:
> >
> > > On Mon, 8 Feb 2021 at 6:38 AM, Yugo NAGATA wrote:
> > >
> >
On Mon, 08 Feb 2021 17:32:46 +0900 (JST)
Kyotaro Horiguchi wrote:
> At Mon, 8 Feb 2021 14:12:35 +0900, Yugo NAGATA wrote in
> > > > > I think the right fix should be that the state should never go from
> > > > > ‘paused’ to ‘pause requested’ so I
On Tue, 09 Feb 2021 10:58:04 +0900 (JST)
Kyotaro Horiguchi wrote:
> At Mon, 8 Feb 2021 17:05:52 +0530, Dilip Kumar wrote
> in
> > On Mon, Feb 8, 2021 at 2:19 PM Yugo NAGATA wrote:
> > >
> > > On Mon, 08 Feb 2021 17:32:46 +0900 (JST)
> > > Kyotaro Horigu
]
https://www.postgresql.org/message-id/flat/CACjxUsP8J6bA4RKxbmwujTVMwMZrgR3AZ7yP5F2XkB-f9w7K7Q%40mail.gmail.com#efbee336d7651ce39bc5ff9574f92002
Regards,
Yugo Nagata
--
Yugo NAGATA
.0/en/delete.html
[2]
https://www.dba-db2.com/2015/04/delete-first-1000-rows-in-a-db2-table-using-fetch-first.html
How do you think it?
--
Yugo NAGATA
diff --git a/src/backend/nodes/copyfuncs.c b/src/backend/nodes/copyfuncs.c
index 297b6ee715..c596bd80ea 100644
--- a/src/backend/nodes/copyfu
On Fri, 17 Dec 2021 09:47:18 +0900
Yugo NAGATA wrote:
> Hello hackers,
>
> We cannot use ORDER BY or LIMIT/OFFSET in the current
> DELETE statement syntax, so all the row matching the
> WHERE condition are deleted. However, the tuple retrieving
> process of DELETE is basica
On Thu, 16 Dec 2021 22:17:58 -0500
Tom Lane wrote:
> Yugo NAGATA writes:
> > We cannot use ORDER BY or LIMIT/OFFSET in the current
> > DELETE statement syntax, so all the row matching the
> > WHERE condition are deleted. However, the tuple retrieving
> > process of
On Thu, 16 Dec 2021 20:56:59 -0700
"David G. Johnston" wrote:
> On Thursday, December 16, 2021, Yugo NAGATA wrote:
>
> >
> > Also, here seem to be some use cases. For example,
> > - when you want to delete the specified number of rows from a table
> &g
atures that have been added
> which can expose the order in which the updates happened.
>
> The way to solve those cases would be to use serializable isolation
> (or even just repeatable read in this case). Wouldn't that also solve
> the DELETE serialization failure too?
Do you mean such serialization failures would be avoided in
SERIALIZABLE or REPATABLE READ by aborting the transaction, such
serialization failures may be accepted in READ COMMITTED?
Regards,
Yugo Nagata
--
Yugo NAGATA
istics advisor.
> BTW Why is "qual" in
>
> static void
> AddMultiColumnStatisticsForQual(void* qual, ExplainState *es)
>
> declared as "void *"? Shouldn't that be "List *"?
When I tested this extension using TPC-H queries, it raised segmentation
fault in this function. I think the cause would be around this argument.
Regards,
Yugo Nagata
--
Yugo NAGATA
On Fri, 19 Mar 2021 19:58:27 +0300
Konstantin Knizhnik wrote:
>
>
> On 19.03.2021 12:17, Yugo NAGATA wrote:
> > On Wed, 10 Mar 2021 03:00:25 +0100
> > Tomas Vondra wrote:
> >
> >> What is being proposed here - an extension suggesting which statistics
> &
_acctbal_c_phone, 2200) already
exists.
Regards,
Yugo Nagata
On Sat, 20 Mar 2021 12:41:44 +0300
Konstantin Knizhnik wrote:
>
>
> On 19.03.2021 20:32, Zhihong Yu wrote:
> > Hi,
> > In AddMultiColumnStatisticsForQual(),
> >
> > + /* Loop until we considered all
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:
> >
> >
description about which situations IVM is effective or not in
- Improve hint in log messages
- Reorganize include directives in codes
Regards,
Yugo Nagata
--
Yugo NAGATA
IVM_patches_v16.tar.gz
Description: application/gzip
;
> + * check_aggregate_supports_ivm
> + *
> + * Check if the given aggregate function is supporting
Regards,
Yugo Nagata
--
Yugo NAGATA
IVM_patches_v17.tar.gz
Description: application/gzip
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
>
ks version of
> that sort of thing leads to ideas like, I dunno, update chains
> containing differential update trees to be compacted later... egad!)
I am interested in papers you mentioned! Are they literatures in context of
incremental view maintenance?
Regards,
Yugo Nagata
--
Yugo NAGATA
pparently indexed views are Graefe's name for MVs, and
> apparently this paper has a section on MVCC systems which sounds
> interesting for us.
>
> [1] https://dsf.berkeley.edu/cs286/papers/mv-fntdb2012.pdf
> [2] http://pages.cs.wisc.edu/~gangluo/latch.pdf
Thanks for your information! I will also check references
regarding with IVM and concurrency control.
Regards,
Yugo Nagata
--
Yugo NAGATA
atched.
> > Barring any objection, I will push the attached patch to the master.
>
> Pushed. Thanks!
Thanks!
>
> I also pushed the typo-fix patch that I proposed upthread.
>
> Regards,
>
> --
> Fujii Masao
> Advanced Computing Technology Center
> Research and Development Headquarters
> NTT DATA CORPORATION
>
>
--
Yugo NAGATA
Hello Daniel Gustafsson,
On Mon, 15 Nov 2021 14:13:32 +0100
Daniel Gustafsson wrote:
> > On 21 Jul 2021, at 03:49, Yugo NAGATA wrote:
>
> > I attached the updated patch v2, which includes a comment fix and a TAP
> > test.
>
> This patch fails the TAP test
ion of "simple base table" is ambiguous for some
> users.
>
> + IMMVs must be based on simple base tables. It's not supported to
> + create them on top of views or materialized views.
Oh, I forgot to fix the documentation. I'll fix it.
Ragards,
Yugo Nagata
--
Yugo NAGATA
elation "ivm_t_index" already exists
Thank you for pointing out it!
Hmmm, an index is created when IMMV is defined, so CREAE INDEX called
after this would fail... Maybe, we should not create any index automatically
if IMMV is created WITH NO DATA.
I'll fix it after some investigation.
Regards,
Yugo Nagata
--
Yugo NAGATA
r is related to IMMV, especially when We dropped
IVM triggers from the view when REFRESH ... WITH NO DATA is executed [13].
[13]
https://www.postgresql.org/message-id/20210922185343.548883e81b8baef14a0193c5%40sraoss.co.jp
---
Regards,
Yugo Nagata
--
Yugo NAGATA
ons.
https://www.postgresql.org/message-id/20211129144826.c9d42c1f61495c6983d8b6b1%40sraoss.co.jp
Regards,
Yugo Nagata
--
Yugo NAGATA
it is basically a "view" and it should not contains any data irrelevant to its
definition and underlying tables. If we would have a feature to update a
materialized view direcly, maybe, it should behave as updatable-view as well
as normal (virtual) views, although I am not sure
--
Yugo NAGATA
; pessimistic concurrency control, (2) finer-grained locking, and (3)
> not needing to issue explicit LOCK commands.
> --
> Robert Haas
> EnterpriseDB: http://www.enterprisedb.com
> The Enterprise PostgreSQL Company
--
Yugo Nagata
diff --git a/doc/src/sgml/ref/lock.sgml b/doc
On Tue, 27 Mar 2018 23:28:04 +0900
Yugo Nagata wrote:
I found the previous patch was broken and this can't handle
views that has subqueries as bellow;
CREATE VIEW lock_view6 AS SELECT * from (select * from lock_tbl1) sub;
I fixed this and attached the updated version including addit
eritance children.
> --- 118,125
>
>lock_tbl1
>lock_view6
> ! mvtest_tm
> ! (3 rows)
>
> Best regards,
> --
> Tatsuo Ishii
> SRA OSS, Inc. Japan
> English: http://www.sraoss.co.jp/index_en.php
> Japanese:http://www.sraoss.co.j
On Thu, 29 Mar 2018 17:26:36 -0700
Andres Freund wrote:
Thank you for your comments. I attach a patch to fix issues
you've pointed out.
> Hi,
>
> On 2018-03-28 20:26:48 +0900, Yugo Nagata wrote:
> > diff --git a/doc/src/sgml/ref/lock.sgml b/doc/src/sgml/ref/lock.sgml
> &
On Mon, 2 Apr 2018 18:32:53 +0900
Yugo Nagata wrote:
> On Thu, 29 Mar 2018 17:26:36 -0700
> Andres Freund wrote:
>
> Thank you for your comments. I attach a patch to fix issues
> you've pointed out.
I found a typo in the documentation and attach the updated patch.
;
> >> create view v3 as select * from v1;
> >> begin;
> >> lock v3;
> >> abort;
>
> Shouldn't they be in the regression test?
Added tests for the infinite recursion detection.
Regards,
>
> It's shame that create_view test does no
to
collect information of modified table and its changes (= transition tables),
and then the only last trigger updates the view. This will avoid the
double-counting. I think this implementation also would be a base of
deferred approach implementation in future where "logs" are used instead
of transition tables.
Regards,
Yugo Nagata
--
Yugo Nagata
s.
Actually, post-update state is available in AFTER trigger, and pre-update state
can be calculated by using delta tables (transition tables) and cmin/xmin system
columns (or snapshot). This is the approach my implementation adopts.
>
> On Tue, Sep 17, 2019 at 8:50 AM Yugo Nagata wrote:
>
5.1. Results
- Comparison with the normal view
SELECT * FROM mv ORDER BY v1;
v1 | v2
--+-
10 | 100
11 | 100
1020 | 200
1020 | 222
(4 rows)
SELECT * FROM v ORDER BY v1;
v1 | v2
--+-
10 | 100
11 | 100
1020 | 200
1020 | 222
(4 rows)
Best Regards,
nnect psql meta-commands to
test
the user privilege to a namespace, but I think we can make this more simpler
by using SET SESSION AUTHORIZATION and RESET AUTHORIZATION.
Regards,
--
Yugo Nagata
cache. You have
to install libmemcached.
, but maybe libmemcached-devel is correct instead of libmemcached?
Regards,
--
Yugo Nagata
--
Yugo Nagata
Hi,
I apologize that I accidentally sent the following email to this list.
Please disregard this.
I am sorry for making a lot of noise.
Regard,
On Tue, 26 Mar 2019 20:38:31 +0900
Yugo Nagata wrote:
> Hi,
>
> One of our clients suggested that the installation document[1] lacks
>
bmemcached-devel is correct instead of libmemcached?
>
> I don't think so. "libmemcached-devel" is just a package name in a
> cetain Linux distribution. "libmemcached" is a more geneal and non
> distribution dependent term.
Thanks for your explaination. I understood it.
> Best regards,
> --
> Tatsuo Ishii
> SRA OSS, Inc. Japan
> English: http://www.sraoss.co.jp/index_en.php
> Japanese:http://www.sraoss.co.jp
--
Yugo Nagata
On Thu, 27 Dec 2018 21:57:26 +0900
Yugo Nagata wrote:
> Hi,
>
> I would like to implement Incremental View Maintenance (IVM) on PostgreSQL.
I am now working on an initial patch for implementing IVM on PostgreSQL.
This enables materialized views to be updated incrementally after one
Hi,
I've updated the wiki page of Incremental View Maintenance.
https://wiki.postgresql.org/wiki/Incremental_View_Maintenance
On Thu, 11 Jul 2019 13:28:04 +0900
Yugo Nagata wrote:
> Hi Thomas,
>
> Thank you for your review and discussion on this patch!
>
> > >
values are contained in views as hidden columns and use them to calculate
new avg value instead of using old avg values.
Regards,
On Fri, 26 Jul 2019 11:35:53 +0900
Yugo Nagata wrote:
> Hi,
>
> I've updated the wiki page of Incremental View Maintenance.
>
> https://wiki
On Sun, 31 Dec 2017 11:57:02 -0500
Tom Lane wrote:
> Yugo Nagata writes:
> > Attached is a patch to implement a feature to get the current function
> > name by GET DIAGNOSTICS in PL/pgSQL function.
>
> While this is certainly not a very large patch, it's still code th
On Thu, 25 Jan 2018 20:51:41 +1300
Thomas Munro wrote:
> On Sun, Dec 31, 2017 at 11:57 PM, Yugo Nagata wrote:
> > On Fri, 29 Dec 2017 23:39:39 +0900 (JST)
> > Tatsuo Ishii wrote:
> >> Your addition to the doc:
> >> + Automatically updatable views (see )
>
On Fri, 26 Jan 2018 21:30:49 +0900
Yugo Nagata wrote:
> On Thu, 25 Jan 2018 20:51:41 +1300
> Thomas Munro wrote:
>
> > On Sun, Dec 31, 2017 at 11:57 PM, Yugo Nagata wrote:
> > > On Fri, 29 Dec 2017 23:39:39 +0900 (JST)
> > > Tatsuo Ishii wrote
and attached a updated patch v6.
Regards,
>
> Best regards,
> --
> Tatsuo Ishii
> SRA OSS, Inc. Japan
> English: http://www.sraoss.co.jp/index_en.php
> Japanese:http://www.sraoss.co.jp
--
Yugo Nagata
diff --git a/doc/src/sgml/ref/lock.sgml b/doc/src/sgml/ref/lock.sgml
index b
views can be locked, that is,
> + * views whose definition are simple and that doesn't have
> + * instead of rules or triggers are lockable.
>
> s/definition are simple and that doesn't/definition is simple and that don't/
> s/instead of/INSTEAD OF/ ?
Thank you for pointi
re i = 1;
DECLARE CURSOR
postgres=# fetch from c;
i
---
1
(1 row)
postgres=# update test set i=i+1 where current of c;
ERROR: cannot extract system attribute from virtual tuple
===
The patch fixes the error and allows this update successfully.
Regards,
--
Yugo Nagata
diff --git a/src/backend/
On Thu, 1 Feb 2018 01:33:49 +0900
Yugo Nagata wrote:
I'm sorry the patch attached in the previous mail is broken and
not raises a compile error. I attached the fixed patch.
Regards,
> Hi,
>
> I found that updating a cursor by using CURRENT OF causes the
> following error
> > No objection from me.
>
> I marked this as "Ready for Committer".
Thank you for reviewing the patch!
Regards,
>
> Best regards,
> --
> Tatsuo Ishii
> SRA OSS, Inc. Japan
> English: http://www.sraoss.co.jp/index_en.php
> Japanese:http://www.sraoss.co.jp
--
Yugo Nagata
On Wed, 31 Jan 2018 21:12:51 -0500
Tom Lane wrote:
> Yugo Nagata writes:
> > I'm sorry the patch attached in the previous mail is broken and
> > not raises a compile error. I attached the fixed patch.
>
> This patch is almost certainly wrong: you can't ass
related functions in matview.c so that ones
which have relationship will be located closely. Moreover, I added more
comments.
Regards,
Yugo Nagata
--
Yugo Nagata
IVM_v8.patch.gz
Description: application/gzip
VM, so I'll think about that a little more
Regards,
Yugo Nagata
>
> Best regards,
> --
> Tatsuo Ishii
> SRA OSS, Inc. Japan
> English: http://www.sraoss.co.jp/index_en.php
> Japanese:http://www.sraoss.co.jp
--
Yugo Nagata
s.
>
> Best regards,
> --
> Tatsuo Ishii
> SRA OSS, Inc. Japan
> English: http://www.sraoss.co.jp/index_en.php
> Japanese:http://www.sraoss.co.jp
--
Yugo Nagata
1 - 100 of 567 matches
Mail list logo
