298b5fee2849abef86aff
Make materialized views participate in predicate locking
Regards,
Yugo Nagata
> I learned a few things creating it this time:
>
> * I can get confused over C function names and SQL function names in
>commit messages.
>
> * The sections and orde
is unnecessary,
as similar to that there are no option to omitting to create tables.
Regards,
Yugo Nagata
--
Yugo NAGATA
On Thu, 1 Jun 2023 23:59:09 +0900
Yugo NAGATA wrote:
> Hello hackers,
>
> Here's a rebased version of the patch-set adding Incremental View
> Maintenance support for PostgreSQL. That was discussed in [1].
> [1]
> https://www.postgresql.o
gregations, and also join it with other tables.
What do you think of using ENR for this way?
Regards,
Yugo Nagata
--
Yugo NAGATA
diff --git a/src/backend/executor/spi.c b/src/backend/executor/spi.c
index e3a170c38b..27e94ecc87 100644
--- a/src/backend/executor/spi.c
+++ b/src/backend/executor/spi.
lso useful to identify a problematic row when
an error like
"ERROR: unexpected chunk number ... (expected ...) for toast value"
occurs.
The patch is a just a concept patch and not including documentation
and tests.
What do you think about this feature?
Regards,
Yugo Nagata
--
Yug
option is prohibited.
postgres=# select 1 \watch interval=3 4
\watch: incorrect interval value '4'
I think it is ok, but this error message seems not user-friendly because,
in the above example, interval values itself is correct, but it seems just
a syntax error. I wonder it is better to use "watch interval must be specified
only once" or such here, as the past patch.
+
+If number of iterations is specified - query will be executed only
+given number of times.
+
Is it common to use "-" here? I think using comma like
"If number of iterations is specified, "
is natural.
Regards,
Yugo Nagata
--
Yugo NAGATA
he
portal was executed". I'm worried that this makes users confused. For example,
a user may think the average numbers of rows returned by a statement is given by
rows/calls, but it is not always correct because some statements could be
executed
with multiple portal runs.
Although it might not big i
:walsender] DETAIL: The connection user "r1" requires the REPLICATION
> attribute.
However, if we need this change, how about using
"DETAIL: The connection user "r1" must have the REPLICATION attribute."
This pattern is used in other part like check_object_ownershi
;--help" might be intended rather than "--version" to check
supported options? Even so, ctags would have other option whose name contains
"-e" than Emacs support, so this check could end in a wrong result. Therefore,
it seems to me that it is better to check immediately if e
gs on Mac failed anyway. Do we want make_etags to
> restore the previous behavior? i.e. 'etags' program not found
>
> >> If so, we should revert the changes of make_etags by the commit and
> >> make make_etags work with that ctags?
>
> I think ctags on Mac canno
On Wed, 01 Feb 2023 11:47:23 -0500
Tom Lane wrote:
> Yugo NAGATA writes:
> > Antonin Houska wrote:
> >> While working on [1] I noticed that if RLS gets enabled, the COPY TO
> >> command
> >> includes the contents of child table into the result, although t
.
However, I think we would want a comment on the added line. Also, the
attached test should be placed in the regression test.
Regards,
Yugo Nagata
>
> [1] https://commitfest.postgresql.org/41/3641/
>
> --
> Antonin Houska
> Web: https://www.cybertec-postgresql.com
>
--
Yugo NAGATA
│ U
> datetime │ 2023-02-01 01:16:44.704036+01
> oldrow │ {"year": 2021, "brand": "Sunrise", "winery": "Concha y Toro",
> "bottles": 12, "variety": "Chardonnay"}
> newrow │ {"bottles": 108}
> ─[ RECORD 2
> ]
> op │ U
> datetime │ 2023-02-01 01:16:44.704036+01
> oldrow │ {"year": 2022, "brand": "Sunrise", "winery": "Concha y Toro",
> "bottles": 12, "variety": "Merlot"}
> newrow │ {"bottles": 132}
>
> --
> Álvaro HerreraBreisgau, Deutschland — https://www.EnterpriseDB.com/
> "La gente vulgar sólo piensa en pasar el tiempo;
> el que tiene talento, en aprovecharlo"
>
>
--
Yugo NAGATA
On Wed, 1 Feb 2023 16:52:07 +1300
David Rowley wrote:
> On Wed, 1 Feb 2023 at 15:53, Yugo NAGATA wrote:
> > Maybe, you missed to set plan_cache_mode to force_generic_plan.
> > "Subplan Removed" doesn't appear when using a custom plan.
>
> I wouldn't say that's
On Wed, 1 Feb 2023 14:37:27 +0800
Julien Rouhaud wrote:
> Hi,
>
> On Tue, Jan 31, 2023 at 11:17:22AM +0900, Yugo NAGATA wrote:
> >
> > On Mon, 30 Jan 2023 16:05:52 -0500
> > Tom Lane wrote:
> >
> > > If you have no update script, why call it a
= $3))
-> Seq Scan on ab_a2_b3 ab_3 (actual rows=0 loops=1)
Filter: ((a >= $1) AND (a <= $2) AND (b <= $3))
(8 rows)
Regards,
Yugo Nagata
--
Yugo NAGATA
Hi,
Thank you for your comment.
On Mon, 30 Jan 2023 16:05:52 -0500
Tom Lane wrote:
> Yugo NAGATA writes:
> > Currently, even when we don't need to execute any command to update an
> > extension from one version to the next, we need to provide an update
> > script tha
dates_without_script.
Presence of update script has higher priority than the option. Therefore,
if an update script is provided, the script will be executed even if this
update is specified in updates_without_script.
What do you think of this feature?
Any feedback would be appreciated.
Regards,
Y
On Thu, 1 Dec 2022 15:48:21 +0900
Michael Paquier wrote:
> On Tue, Oct 18, 2022 at 05:29:58PM +0900, Yugo NAGATA wrote:
> > Thank you for your review. I agree that an isolation test is required.
> > The attached patch contains the test using the scenario as explained in
> &
nking about this point, and it seems to me that we could just
> do s/the given subquery/a subquery/. But perhaps you have a different
> view on the matter?
+1
I also was just about to send a patch updated as so, and this is attached.
Regards,
Yugo Nagata
> --
> Michael
--
Yugo NAGATA
Hello,
I found that qual_is_pushdown_safe() has an argument "subquery"
that is not used in the function. This argument has not been
referred to since the commit 964c0d0f80e485dd3a4073e073ddfd9bfdda90b2.
I think we can remove this if there is no special reason.
Regards,
Yugo Nagata
On Thu, 10 Nov 2022 15:33:37 -0500
Tom Lane wrote:
> Yugo NAGATA writes:
> > Tom Lane wrote:
> >> Hmm. Maybe the right way to think about this is "if we have completed an
> >> EXECUTE, and not yet received a following SYNC, then report that we are in
>
ion,
although I have once withdrawn this for not breaking backward compatibility.
Attached is the same patch of [1].
[1]
https://www.postgresql.org/message-id/20220728105134.d5ce51dd756b3149e9b9c52c%40sraoss.co.jp
Regards,
Yugo Nagata
--
Yugo NAGATA
On Wed, 09 Nov 2022 11:17:29 -0500
Tom Lane wrote:
> Yugo NAGATA writes:
> > Tom Lane wrote:
> >> What do you think of the attached wording?
>
> > It looks good to me. That describes the expected behaviour exactly.
>
> Pushed that, then.
Thank you.
>
On Sun, 06 Nov 2022 12:54:17 -0500
Tom Lane wrote:
> Yugo NAGATA writes:
> >> The attached patch tries to add comments explaining it on the functions.
>
> > I forward it to the hackers list because the patch is to fix comments.
>
> What do you think of the attac
ake_ctags -e) and it was
just for testing the patch. Similarly, someone who runs mistakenly this
command might want this option. However, as you say, there've been no
complain about this, so I don't feel it necessary so much. Maybe, users
of this command would be able to remove tags by their selves easily.
Regards,
Yugo Nagata
--
Yugo NAGATA
> Best reagards,
> --
> Tatsuo Ishii
> SRA OSS LLC
> English: http://www.sraoss.co.jp/index_en/
> Japanese:http://www.sraoss.co.jp
--
Yugo NAGATA
> > I fixed the patch to allow use both -e and -n options together.
> >>
> >> Thanks. I have made mostly cosmetic changes so that it is more
> >> consistent with existing scripts.
> >>
> >> I would like to push v6 patch if there's no objection.
> >
objection.
I am fine with this patch.
By the way, in passing, how about adding "tags" and "TAGS" to
.gitignore file?
>
> Best reagards,
> --
> Tatsuo Ishii
> SRA OSS LLC
> English: http://www.sraoss.co.jp/index_en/
> Japanese:http://www.sraoss.co.jp
--
Yugo NAGATA
Hello Micheal-san,
On Thu, 13 Oct 2022 17:02:06 +0900
Michael Paquier wrote:
> On Fri, Sep 30, 2022 at 10:12:13AM +0900, Yugo NAGATA wrote:
> > Thank you for comment. Do you think it can be marked as Ready for Commiter?
>
> Matviews have been discarded from needing predic
gt; the links.
>
> Also I have changed make_etags so that it exec make_ctags, which seems
> to be the consensus.
Thank you for following up my patch.
I fixed the patch to allow use both -e and -n options together.
Regards,
Yugo Nagata
>
> Best reagards,
> --
> Tatsuo Is
Hello
On Mon, 10 Oct 2022 12:04:22 +0200
Alvaro Herrera wrote:
> Hello
>
> On 2022-Oct-07, Yugo NAGATA wrote:
>
> > I found that tag files generated by src/tools/make_ctags
> > doesn't include some keywords, that were field names of node
> > structs, for examp
(equal_ignore);
In this case, pg_node_attr is mistakenly interpreted to be
the name of the field. So, I propose to use -I option of ctags
to ignore the marco name. Attached is a patch to do it.
Regards,
Yugo Nagata
--
Yugo NAGATA
diff --git a/src/tools/make_ctags b/src/tools/make_ctags
index
Hi,
On Tue, 9 Aug 2022 00:21:02 +0900
Yugo NAGATA wrote:
> On Wed, 27 Jul 2022 22:50:55 -0400
> Tom Lane wrote:
>
> > Yugo NAGATA writes:
> > > I've looked at the commited fix. What I wonder is whether a change in
> > > IsInTransactionBlock() is necessary o
On Fri, 9 Sep 2022 16:27:45 +0530
Dilip Kumar wrote:
> On Tue, Jul 26, 2022 at 3:31 PM Richard Guo wrote:
> >
> >
> > On Tue, Jul 26, 2022 at 3:44 PM Yugo NAGATA wrote:
> >>
> >> If such two transactions run concurrently, a write skew anomaly occur
Hi,
On Mon, 12 Sep 2022 17:03:43 +0200
Alvaro Herrera wrote:
> On 2022-Mar-28, Yugo NAGATA wrote:
>
> > On Fri, 25 Mar 2022 16:19:54 -0400
> > Tom Lane wrote:
>
> > > I am not convinced this is a great idea. The current behavior is that
> > > a sta
ase table
> can not be blocked, that is to say, the base table can still record logs
> during incremental refresh,
> as long as we use same snapshot when incrementally updating.
>
> do you think there will be any problems with this solution?
I guess the deferred maintenance process would be basically what similar
to above. Especially, as you say, we need to merge incremental information
in some way before calculating deltas on the view. I investigated some
research papers, but I'll review again before working on deferred approach
design.
Regards,
Yugo Nagata
--
Yugo NAGATA
uire predicate
locks on materialized views as well.
What do you think about it?
Regards,
Yugo Nagata
--
Yugo NAGATA
diff --git a/src/backend/storage/lmgr/predicate.c b/src/backend/storage/lmgr/predicate.c
index 5136da6ea3..6d414bfcc9 100644
--- a/src/backend/storage/lmgr/predicate.c
+++ b/src/b
>
> Pushed. Thanks!
Thanks!
>
> Regards,
>
> --
> Fujii Masao
> Advanced Computing Technology Center
> Research and Development Headquarters
> NTT DATA CORPORATION
--
Yugo NAGATA
Fujii Masao
> Advanced Computing Technology Center
> Research and Development Headquarters
> NTT DATA CORPORATION
--
Yugo NAGATA
..0.093 rows=0 loops=1)
-> Bitmap Index Scan on mv_index (cost=0.00..4.43 rows=1
width=0) (actual time=0.065..0.065 rows=1 loops=1)
Index Cond: (id = diff.id)
-> Bitmap Index Scan on mv_index (cost=0.00..4.43 rows=1
width=0) (actual time=0.021..0.021 rows=0 loops=1)
Index Cond: (id IS NULL)
Planning Time: 0.666 ms
Execution Time: 0.399 ms
(15 rows)
Regards,
Yugo Nagata
--
Yugo NAGATA
On Fri, 8 Jul 2022 16:50:10 +0900
Ian Lawrence Barwick wrote:
> 2022年7月8日(金) 14:06 Fujii Masao :
> > On 2022/07/08 11:19, Yugo NAGATA wrote:
> > >> You added "foreign tables" for BEFORE statement-level trigger as the
> > >> above, but ISTM that yo
Hello Fujii-san,
Thank you for reviewing the patch!
On Fri, 8 Jul 2022 00:54:37 +0900
Fujii Masao wrote:
>
>
> On 2022/06/30 19:38, Yugo NAGATA wrote:
> > Hello,
> >
> > I propose supporting TRUNCATE triggers on foreign tables
> > because some F
On Fri, 08 Jul 2022 09:44:10 +0900 (JST)
Kyotaro Horiguchi wrote:
> At Fri, 8 Jul 2022 01:06:18 +0900, Fujii Masao
> wrote in
> >
> >
> > On 2022/07/08 0:33, Tom Lane wrote:
> > > Fujii Masao writes:
> > >> On 2022/06/30 10:48, Yugo NAGATA wr
On Mon, 4 Jul 2022 15:51:32 +0900
Michael Paquier wrote:
> On Wed, Jun 29, 2022 at 05:29:50PM +0900, Yugo NAGATA wrote:
> > Thank you for reviewing the patch. I attached the updated patch.
>
> Thanks for the new version. I have looked at that again, and the set
> of
Hello,
I propose supporting TRUNCATE triggers on foreign tables
because some FDW now supports TRUNCATE. I think such triggers
are useful for audit logging or for preventing undesired
truncate.
Patch attached.
Regards,
Yugo Nagata
--
Yugo NAGATA
diff --git a/contrib/postgres_fdw/expected
. So, what
about adding a test this message output? We can add this test
for file_fdw because it is one of the such foreign data wrappers.
I attached a patch.
[1] https://postgr.es/m/20220527172543.0a2fdb469cf048b81c096...@sraoss.co.jp
--
Yugo NAGATA
diff --git a/contrib/file_fdw/expected/file
INV_WRITE = 0x4
> +-- INV_READ = 0x4
> +-- INV_WRITE = 0x2
> Good catch! This one is kind of independent, so I have fixed it
> separately, in all the expected output files.
Thanks!
--
Yugo NAGATA
diff --git a/doc/src/sgml/lobj.sgml b/doc/src/sgml/lobj.sgml
inde
the error in each of lo_truncate and lo_truncate64
per Michael's comment in the other post.
Regards,
Yugo Nagata
--
Yugo NAGATA
diff --git a/src/backend/libpq/be-fsstubs.c b/src/backend/libpq/be-fsstubs.c
index 5804532881..19c0a0c5de 100644
--- a/src/backend/libpq/be-fsstubs.c
+++ b/src/backend/li
nd done as of 0efa513.
Thank you!
--
Yugo NAGATA
On Sat, 28 May 2022 18:00:54 +0900
Michael Paquier wrote:
> On Fri, May 27, 2022 at 03:30:28PM +0900, Yugo NAGATA wrote:
> > Currently, lo_creat(e), lo_import, lo_unlink, lowrite, lo_put,
> > and lo_from_bytea are allowed even in read-only transactions.
> > By using
uot;,
but it is just because the foreign table has no handler,
not due to TRUNCATE.
The patch is attached.
Regards,
Yugo Nagata
--
Yugo NAGATA
diff --git a/src/test/regress/expected/foreign_data.out b/src/test/regress/expected/foreign_data.out
index 5bf03680d2..33505352cc 100644
--- a/src/t
prevent such writes operations
on large object in read-only transactions, like:
postgres=# SELECT lo_create(42);
ERROR: cannot execute lo_create in a read-only transaction
The patch is attached.
Regards,
Yugo Nagata
--
Yugo NAGATA
diff --git a/src/backend/libpq/be-fsstubs.c b/src/backend/libpq
Following your advice, I am going to write a readers guide referring to the past
posts of Andres and Rebert.
Regards,
Yugo Nagata
--
Yugo NAGATA
ions', but it has been removed due to this commit.
>
> Yes, your patch removed "".
>
> > So,
> > I would like to get back this as it was. I attached the patch.
>
> This produces errors. Needs ";" postfix?
Oops. Yes, it needs ';'. Also, I found another "&qu
or.
Currently, pgbench fails to execute the above script in prepared mode
because it prepares the entire script in advance just before the first
command execution. This patch does not change the semantic.
> BTW, the cfbot says the patch is failing to apply anyway ...
> I think it was sideswiped by 4a3
be
> precisou information. I would suggest leave the log items as it is.
>
> Patch attached.
Even applying this patch, "make postgres-A4.pdf" arises the warning on my
machine. After some investigations, I found that previous document had a break
after 'num_transactions', but it
On Fri, 25 Mar 2022 09:14:00 +0900 (JST)
Tatsuo Ishii wrote:
> > Note that the \\g2 just above also needs to be changed.
>
> Oops. Thanks. New patch attached. Test has passed on my machine.
This patch works for me. I think it is ok to use \N instead of \gN.
Regards,
Yugo Naga
iginal 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 Nagata
--
Yugo NAGATA
diff --git a/src/bi
d 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
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
les". 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
used. 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
t.
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 both serialization and deadlock
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
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
gt; 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 patch-set.
fo 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
eateIndexOnIMMV.
This was also necessary for supporting CTEs, but unnecessary in the current
patch, so I'll fix it, too.
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
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
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
atic inline __u32 rol32(__u32 word, unsigned int shift)
{
return (word << (shift & 31)) | (word >> ((-shift) & 31));
}
[1] https://github.com/torvalds/linux/blob/master/include/linux/bitops.h
[2] https://lore.kernel.org/lkml/20190609164129.126354...@linuxfoundation.org/
R
ine when started with 2 clients,
> otherwise they get stuck because the first client waits for the other one
> which does not exists (the point is to generate deadlocks and other
> errors). Maybe this is your issue?
That seems to be right. It got stuck when I used -T option rather than -t,
i
On Fri, 18 Feb 2022 12:22:32 +0900
Fujii Masao wrote:
>
>
> On 2022/02/07 19:14, Yugo NAGATA wrote:
> > Agreed. I updated the patch to add a comment about 'oldId'.
>
> Thanks for updating the patch! I slightly modified the patch and pushed it.
Thanks!
>
> Rega
Hello, Fujii-san,
On Fri, 4 Feb 2022 09:08:22 +0900
Fujii Masao wrote:
>
>
> On 2022/02/04 1:46, Yugo NAGATA wrote:
> > Hello,
> >
> > I found a old parameter name 'heapRelation' in the comment
> > of CheckIndexCompatible. This parameter was removed by 5f173
Hello,
I found a old parameter name 'heapRelation' in the comment
of CheckIndexCompatible. This parameter was removed by 5f173040.
Attached is a patch to remove it from the comment.
Regards,
Yugo Nagata
--
Yugo NAGATA
diff --git a/src/backend/commands/indexcmds.c b/src/backend/commands
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 check
.
Regards,
Yugo Nagata
--
Yugo NAGATA
ich 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
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
>
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
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
/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/copyfuncs.c
/www.postgresql.org/message-id/flat/CACjxUsP8J6bA4RKxbmwujTVMwMZrgR3AZ7yP5F2XkB-f9w7K7Q%40mail.gmail.com#efbee336d7651ce39bc5ff9574f92002
Regards,
Yugo Nagata
--
Yugo NAGATA
ically 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/20211129144826.c9d42c1f61495c6983d8b6b1%40sraoss.co.jp
Regards,
Yugo Nagata
--
Yugo NAGATA
ed 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
on "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
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
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 t
t; 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 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.
>
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 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 update
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
mp, 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
lumns (__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
+ 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 -> CreateIndexOnIMMV
>
> + (errmsg("could not create an index on materialized view
> \"%s\" automatically",
>
> It would be nice to mention the reason is the lack of primary key.
>
> + /* create no index, just notice that an appropriate index is
> necessary for efficient, IVM */
>
> for efficient -> for efficiency.
I'll fix them. Thanks.
Regards,
Yugo Nagata
--
Yugo NAGATA
d the comment slightly and ran pgindent. Barring any
> > objection,
> > I will commit this patch only in master and v14.
>
> Pushed. Thanks!
Thank you!
--
Yugo NAGATA
101 - 200 of 459 matches
Mail list logo
