;
SELECT * FROM mv_ivm_group ORDER BY 1;
sum
-
150
(1 row)
INSERT INTO mv_base_a VALUES(6,20);
SELECT * FROM mv_ivm_group ORDER BY 1;
sum
-
170
(1 row)
===
On Thu, 20 Jun 2019 16:44:10 +0900
Yugo Nagata wrote:
> Hi h
Hi Greg,
On Wed, 3 Apr 2019 17:41:36 -0400
Greg Stark wrote:
> On Sun, 31 Mar 2019 at 23:22, Yugo Nagata wrote:
> >
> > Firstly, this will handle simple definition views which includes only
> > selection, projection, and join. Standard aggregations (count, sum, avg,
Hi Thomas,
Thank you for your review and discussion on this patch!
> > 2019年7月8日(月) 15:32 Thomas Munro :
> >
> > > On Fri, Jun 28, 2019 at 10:56 PM Yugo Nagata wrote:
> > > > Attached is a WIP patch of IVM which supports some aggregate functions.
> >
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
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, 1 Mar 2018 14:29:58 -0800
Andres Freund wrote:
> Hi,
>
> On 2018-01-11 11:03:26 +0900, Yugo Nagata wrote:
> > However, I don't inisist on this patch, so If anyone other don't need this
> > feature, I'll withdraw this.
>
> Given this is where
osing a performance
> cost on unrelated queries.
I would like to elaborate my patch if needed and possible. Any suggestion
would be appriciated.
Thanks,
>
> regards, tom lane
--
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 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
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
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:
> > >
> >
le_x' AS name, * FROM table_x
> > UNION
> > SELECT 'table_y' AS name, * FROM table_y
> > ;
> > CREATE VIEW
> > TABLE xy_union_v;
> > name | id |data
> > -++
> > table_y | 2 | 0.0528458947672874
>
auto_explain.log_min_duration
unless this is set -1 to disable logging. If log_before_query is
enabled, only duration time is logged after query execution as in
the case of when both log_statement and log_min_duration_statement
are enabled.
Regards,
Yugo Nagata
--
Yugo NAGATA
>F
On Wed, 26 Feb 2020 18:51:21 +0100
Julien Rouhaud wrote:
> On Thu, Feb 27, 2020 at 02:35:18AM +0900, Yugo NAGATA wrote:
> > Hi,
> >
> > Attached is a patch for allowing auto_explain to log plans before
> > queries are executed.
> >
> > Currently, a
On Thu, 27 Feb 2020 14:14:41 +0900 (JST)
Kyotaro Horiguchi wrote:
> Hello.
>
> At Thu, 27 Feb 2020 10:18:16 +0900, Yugo NAGATA wrote
> in
> > On Wed, 26 Feb 2020 18:51:21 +0100
> > Julien Rouhaud wrote:
> >
> > > On Thu, Feb 27, 2020 at 02:35:18
On Thu, 27 Feb 2020 06:27:24 +0100
Pavel Stehule wrote:
> čt 27. 2. 2020 v 6:16 odesílatel Kyotaro Horiguchi
> napsal:
>
> > Hello.
> >
> > At Thu, 27 Feb 2020 10:18:16 +0900, Yugo NAGATA
> > wrote in
> > > On Wed, 26 Feb 2020 18:51:21 +0100
> &g
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,
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:
> >
> >
u could tell us what your use cases of materialized
view is and whether our implementation suits your needs or not.
Regards,
Yugo Nagata
--
Yugo NAGATA
provides the exact this feature and I think this will meet
your needs.
> As soon as my coworker gets that example built up I'll send a followup with
> it attached.
Great! We are looking forward to it.
Regards,
Yugo Nagata
--
Yugo NAGATA
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
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
]
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
,
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
(saving some
> indentation).
Yes. I'll fix.
> + check_stack_depth();
> +
> + if (node == NULL)
> + return false;
>
> It seems the node check can be placed ahead of the stack depth check.
OK.
> + * CreateindexOnIMMV
>
> CreateindexOnIMMV ->
ns (__ivm_count__ etc.), and in
the opposite case, we need to create them again. The former (IMMV->IVM) might be
easer, but for the latter (IVM->IMMV) I wonder we would need to re-create IMMV.
Regards,
Yugo Nagata
--
Yugo NAGATA
pg_dump, following error occurs.
>
> ERROR: ALTER action ADD CONSTRAINT cannot be performed on relation "ivm_t"
> DETAIL: This operation is not supported for materialized views.
Good catch! It was my mistake creating unique constraints on IMMV in spite of
we cannot defined them via SQL. I'll fix it to use unique indexes instead of
constraints.
Regards,
Yugo Nagata
--
Yugo NAGATA
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&q
Hello Fujii-san,
On Tue, 7 Sep 2021 02:34:17 +0900
Fujii Masao wrote:
> On 2021/07/29 13:23, Yugo NAGATA wrote:
> > Hello,
> >
> > On Fri, 18 Jun 2021 15:58:48 +0200 (CEST)
> > Fabien COELHO wrote:
> >
> >> Attached Yugo-san patch with some updates d
de. There is a mention about libpq
supporting pipeline, so I think we can also mention that of pgbench.
There are other minor improvement on pgbench, but pgbench is just a
benchnark tool and its changes do not directly affect to user application,
so maybe we don't have to describe all in the release notes.
Regards,
Yugo Nagata
--
Yugo NAGATA
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.
> >
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
ber@entry=199) at
> > /home/andrew/pgl/pg_head/src/backend/utils/error/assert.c:69
>
> That assert just got added a few days ago, so that's why the patch
> seemed OK before.
Thank you for letting me know. I'll fix it.
--
Yugo NAGATA
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
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)
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
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
LE, and I heard
> > > that a couple of forks already ship Marina's patch set.
I got interested in this and now looking into the patch and the past
discussion.
If anyone other won't do it and there are no objection, I would like to rebase
this. Is that okay?
Regards,
Y
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
101 - 200 of 597 matches
Mail list logo
