Fix a typo in rewriteHandler.c
Hi,
I've attached the patch for the following rewriteTargetView comments.
Assert(parsetree->resultRelation == new_rt_index);
/*
* For INSERT/UPDATE we must also update resnos in the targetlist to refer
* to columns of the base relation, since those indicate the target
* columns to be affected.
*
* Note that this destroys the resno ordering of the targetlist, but that
* will be fixed when we recurse through rewriteQuery, which will invoke
* rewriteTargetListIU again on the updated targetlist.
*/
if (parsetree->commandType != CMD_DELETE)
{
foreach(lc, parsetree->targetList)
s/rewriteQuery/RewriteQuery
regards,
Sho Kato
diff --git a/src/backend/rewrite/rewriteHandler.c
b/src/backend/rewrite/rewriteHandler.c
index 5a7b914183..b486ab559a 100644
--- a/src/backend/rewrite/rewriteHandler.c
+++ b/src/backend/rewrite/rewriteHandler.c
@@ -3362,7 +3362,7 @@ rewriteTargetView(Query *parsetree, Relation view)
* columns to be affected.
*
* Note that this destroys the resno ordering of the targetlist, but
that
-* will be fixed when we recurse through rewriteQuery, which will invoke
+* will be fixed when we recurse through RewriteQuery, which will invoke
* rewriteTargetListIU again on the updated targetlist.
*/
if (parsetree->commandType != CMD_DELETE)
Difference of ecpg japanese translation in PG15
Hello In PG15, ecpg japanese translation are different from other branches. Is there a reason for this? If not, I think it would be better to make it the same as the other branch like the attached patch. regards, sho kato update-japanese-translation.patch Description: update-japanese-translation.patch
Re: [PATCH] Teach pg_waldump to extract FPIs from the WAL
The following review has been posted through the commitfest application:
make installcheck-world: tested, failed
Implements feature: tested, failed
Spec compliant: tested, failed
Documentation:tested, failed
Hello,
I tested this patch on Linux and there is no problem.
Also, I reviewed this patch and commented below.
@@ -439,6 +447,107 @@ XLogRecordHasFPW(XLogReaderState *record)
+ if (fork >= 0 && fork <= MAX_FORKNUM)
+ {
+ if (fork)
+ sprintf(forkname, "_%s", forkNames[fork]);
+ else
+ forkname[0] = 0;
+ }
+ else
+ pg_fatal("found invalid fork number: %u", fork);
Should we add the comment if the main fork is saved without "_main" suffix for
code readability?
@@ -679,6 +788,9 @@ usage(void)
" (default: 1 or the value used in
STARTSEG)\n"));
printf(_(" -V, --version output version information, then
exit\n"));
printf(_(" -w, --fullpage only show records with a full page
write\n"));
+ printf(_(" -W, --save-fpi=pathsave full page images to given path as\n"
+" LSN.T.D.R.B_F\n"));
+ printf(_(" -X, --fixup-fpi=path like --save-fpi but apply LSN fixups to
saved page\n"));
printf(_(" -x, --xid=XID only show records with transaction ID
XID\n"));
printf(_(" -z, --stats[=record] show statistics instead of records\n"
" (optionally, show per-record
statistics)\n"));
Since lower-case options are displayed at the top, should we switch the order
of -x and -X?
@@ -972,6 +1093,25 @@ main(int argc, char **argv)
}
}
+ int dir_status = pg_check_dir(config.save_fpw_path);
+
+ if (dir_status < 0)
+ {
+ pg_log_error("could not access output directory: %s",
config.save_fpw_path);
+ goto bad_argument;
+ }
Should we output %s enclosed with \"?
Regards,
Sho Kato
Re: Delay locking partitions during INSERT and UPDATE
The following review has been posted through the commitfest application:
make installcheck-world: tested, failed
Implements feature: tested, failed
Spec compliant: tested, failed
Documentation:tested, failed
Hi,
Increasing the number of clients, I benchmarked with a table partitioned into
1k partition.
I confirmed that this patch improve performance by 10 times or more.
master (commit: 90525d7b4e Date: Tue Jan 15 12:19:21 2019 -0800)
cpu:
Xeon(R) CPU E5-2667 v3 * 2
setup:
create table history(aid int, delta int, mtime timestamp without time zone)
partition by range(aid);
\o /dev/null
select 'create table history_' || x || ' partition of history for values from('
|| x ||') to(' || x+1 || ')' from generate_series(1, 1000) x;
\gexec
benchmark.sql:
\set aid random(1, 1000)
\set delta random(-5000, 5000)
INSERT INTO history VALUES (:aid, :delta, CURRENT_TIMESTAMP);
command line:
pgbench -d testdb -f benchmark.sql -c number_of_clients -T 60 -r -n
Results:
clients | tps_patched | tps_unpatched | tps_unpatched / tps_patched
-+-+---+-
1 |8890 | 841 | 11
2 | 17484 | 1470 | 12
4 | 29218 | 2474 | 12
8 | 48789 | 3876 | 13
16 | 68794 | 4030 | 17
32 | 69550 | 2888 | 24
64 | 71196 | 2555 | 28
128 | 71739 | 2295 | 31
256 | 66548 | 2105 | 32
I wonder why performance does not increase much when the number of clients
exceeds 16.
Even though it is caused by competition of lightweight locks I thought 16
clients are small.
Also, I did make installcheck world, but test partition_prune failed.
However, this test case failed even before applying a patch, so this patch is
not a problem.
One of the results is as follows.
explain (analyze, costs off, summary off, timing off) execute ab_q1 (2, 2, 3);
- QUERY PLAN
--
+ QUERY PLAN
+--
Append (actual rows=0 loops=1)
- Subplans Removed: 6
-> Seq Scan on ab_a2_b1 (actual rows=0 loops=1)
- Filter: ((a >= $1) AND (a <= $2) AND (b <= $3))
+ Filter: ((a >= 2) AND (a <= 2) AND (b <= 3))
-> Seq Scan on ab_a2_b2 (actual rows=0 loops=1)
- Filter: ((a >= $1) AND (a <= $2) AND (b <= $3))
+ Filter: ((a >= 2) AND (a <= 2) AND (b <= 3))
-> Seq Scan on ab_a2_b3 (actual rows=0 loops=1)
- Filter: ((a >= $1) AND (a <= $2) AND (b <= $3))
-(8 rows)
+ Filter: ((a >= 2) AND (a <= 2) AND (b <= 3))
+(7 rows)
regards,
sho kato
