Re: Huge memory consumption on partitioned table with FKs

e names "comparentid" and "ri_GetParentConstOid" are confusing. We should use names like "constraint_root_id", as in Amit-san's patch. Best Regards, -- Keisuke Kuroda NTT Software Innovation Center keisuke.kuroda.3...@gmail.com v2_reduce_ri_SPI-plan-hash.patch Description: Binary data

Re: Huge memory consumption on partitioned table with FKs

ack() is also good. I also confirmed that the patch passed the make check-world. Best Regards, -- Keisuke Kuroda NTT Software Innovation Center keisuke.kuroda.3...@gmail.com

Re: Huge memory consumption on partitioned table with FKs

. Best Regards, -- Keisuke Kuroda NTT Software Innovation Center keisuke.kuroda.3...@gmail.com

Re: Huge memory consumption on partitioned table with FKs

Hi hackers, > > > > I did some cosmetic fooling with this (mostly, rewriting the comments > > YA time) and pushed it. > > Perfect. Thanks for your time on this. > Thank you for your help! I'm glad to solve it. -- Keisuke Kuroda NTT Software Innovation Center keisuke.kuroda.3...@gmail.com

Re: Huge memory consumption on partitioned table with FKs

alog.=) $1 FOR KEY SHARE OF x parent| CacheMemoryContext level | 2 total_bytes | 2101248 total_nblocks | 12 free_bytes| 613256 free_chunks | 1 used_bytes| 1487992 ...(500 same records) Best Regards, -- Keisuke Kuroda NTT Software Innovation Center keisuke.kuroda.3...@gmail.com v1_reduce_ri_SPI-plan-hash.patch Description: Binary data

Re: Huge memory consumption on partitioned table with FKs

Hi Amit-san, > Thanks for checking. Indeed, it should have been added to the January > commit-fest. I've added it to the March one: > > https://commitfest.postgresql.org/32/2930/ Thank you for your quick response! -- Keisuke Kuroda NTT Software Innovation Center keisuke.kuroda.3...@gmail.com

Re: simplifying foreign key/RI checks

age-id/flat/cab4b85d-9292-967d-adf2-be0d803c3e23%40nttcom.co.jp_1 -- Keisuke Kuroda NTT Software Innovation Center keisuke.kuroda.3...@gmail.com

Re: simplifying foreign key/RI checks

blem of using SPI plans in partitions, not just DELETE. I agree with you, I think this is a solution to the current problem. Best Regards, -- Keisuke Kuroda NTT Software Innovation Center keisuke.kuroda.3...@gmail.com

Re: Wrong value in metapage of GIN INDEX.

Hi Moon-san. Thank you for posting. We are testing the GIN index onJSONB type. The default maintenance_work_mem (64MB) was fine in usually cases. However, this problem occurs when indexing very large JSONB data. best regards, Keisuke Kuroda 2019年8月29日(木) 17:20 Moon, Insung : > Dear Hack

Re: Date-time extraneous fields with reserved keywords

to assume that this pattern is also an error. What do you think? As a side note, reserved words such as 'today', 'tomorrow', and 'yesterday' can be used to specify a time. postgres=# select timestamp 'today 01:01:01'; timestamp - 2023-03-03 01:01:01 (1 row) Best Regards, Keisuke Kuroda NTT Comware The new status of this patch is: Waiting on Author

Re: Date-time extraneous fields with reserved keywords

The following review has been posted through the commitfest application: make installcheck-world: tested, passed Implements feature: tested, passed Spec compliant: tested, passed Documentation:tested, passed Thank you for the response and new patch. The scope of impac

Re: control max length of parameter values logged

DD-" to "...--" It is sometimes nice to be able to check the last of strings. For example, if there are difference only in the last of strings of many parameters. Best Regards, Keisuke Kuroda

In PG12, query with float calculations is slower than PG11

lot 2.16% postgres postgres [.] heapgettup_pagemode 2.09% postgres postgres [.] standard_ExecutorRun 2.07% postgres postgres [.] SeqNext 2.03% postgres postgres [.] ExecProcNodeInstr 2.03% postgres postgres [.] tts_virtual_clear PG 12 is still slower compared to PG 11, but the __isinf() situation is better with the patch. Best Regards, Keisuke Kuroda check-float-val.patch Description: Binary data

Re: In PG12, query with float calculations is slower than PG11

[.] heap_getnextslot 2.41% postgres postgres [.] tts_virtual_clear 2.39% postgres postgres [.] SeqNext 2.22% postgres postgres [.] InstrStopNode Best Regards, Keisuke Kuroda 2020年2月7日(金) 3:48 Andres Freund : > Hi, > > On 2020-02

Re: In PG12, query with float calculations is slower than PG11

stgres [.] float84mul 9.62% postgres [vdso] [.] __vdso_clock_gettime 6.45% postgres libc-2.17.so [.] __isinf 5.15% postgres postgres [.] tts_buffer_heap_getsomeattrs 3.83% postgres postgres [.] ExecScan Best Regards, Keisuke Ku

Re: Exposure related to GUC value of ssl_passphrase_command

The following review has been posted through the commitfest application: make installcheck-world: tested, passed Implements feature: tested, passed Spec compliant: tested, passed Documentation:not tested I tested the patch on the master branch (addd034) and it works fi

Logical replication CPU-bound with TRUNCATE/DROP/CREATE many tables

andId is incremented, we could 1767 * see new catalog contents, so execute all 1768 * invalidations. 1769 */ 1770 ReorderBufferExecuteInvalidations(rb, txn); 1771 } 1772 1773 break; Do you have any solutions? -- Keisuke Kuroda NTT Software

Re: Logical replication CPU-bound with TRUNCATE/DROP/CREATE many tables

explaination. I'll try to think about the solution by using XLOG_INVALIDATIONS and referring to the thread "PATCH: logical_work_mem and logical streaming of large in-progress transactions". Best Regards, Keisuke Kuroda NTT Software Innovation Center keisuke.kuroda.3...@gmail.com

Re: Logical replication CPU-bound with TRUNCATE/DROP/CREATE many tables

riting a patch for the same? Thank you! Yes, I would like to write a patch. If you already have a discussed thread or patch for this idea, please let me know. Best Regards, -- Keisuke Kuroda NTT Software Innovation Center keisuke.kuroda.3...@gmail.com

Re: Logical replication CPU-bound with TRUNCATE/DROP/CREATE many tables

n messages. I'm going to write a patch that looks like the following. * Add the process of collecting invalidation to XLOG_XACT_INVALIDATIONS in the form of ReorderBufferChange. * Invalidation is executed in case REORDER_BUFFER_CHANGE_INVALIDATION. Best Regards, -- Keisuke K

Re: Logical replication CPU-bound with TRUNCATE/DROP/CREATE many tables

prove it even before PG13, but I recognize that it's difficult because it uses a PG14 or later mechanism... Best Regards, -- Keisuke Kuroda NTT Software Innovation Center keisuke.kuroda.3...@gmail.com

Re: Logical replication CPU-bound with TRUNCATE/DROP/CREATE many tables

onMessage +1.19% postgres postgres [.] ReadPageInternal +1.19% postgres postgres[.] XLogReadRecord +1.19% postgres postgres[.] socket_is_send_pending hash_seq_search Best Regards, -- Keisuke Kuroda NTT Software Innovation Center keisuke.kuroda.3...@gmail.com

Re: Logical replication CPU-bound with TRUNCATE/DROP/CREATE many tables

postgres[.] AllocSetAlloc 1.61% postgres postgres[.] DecodeXLogRecord 1.29% postgres postgres[.] AllocSetFree 1.29% postgres postgres[.] hash_bytes_uint32 0.97% postgres [vdso] [.] __vdso_gettimeofday 0.97% postgres postgres

Re: Logical replication CPU-bound with TRUNCATE/DROP/CREATE many tables

ipt will wait 10 seconds after INSERT exits before executing TRUNCATE, please wait for it to run. When TRUNCATE completes, the walsender process should be at 100% CPU. Best Regards, -- Keisuke Kuroda NTT Software Innovation Center keisuke.kuroda.3...@gmail.com

Re: Logical replication CPU-bound with TRUNCATE/DROP/CREATE many tables

Hi Amit, Dilip, I am glad to solve this problem, Thanks! Best Regards, -- Keisuke Kuroda NTT Software Innovation Center keisuke.kuroda.3...@gmail.com

Re: Separate GUC for replication origins

_origin_states' easier to understand, although it is a long name. Best Regards, Keisuke Kuroda NTT Comware

Re: [PATCH] Improve code coverage of network address functions

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 Thank you for your patch! I have confirmed that the coverage

Re: [PATCH] Improve code coverage of network address functions

> 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 Sorry, I thought I checked with the commitfest App,

Re: [PATCH] Improve code coverage of network address functions

sing in the convert_network_to_scalar() does not seem to be testing. This is related to the macaddr/macaddr8 type histograms and do not appear to work in a simple test. This should be considered for another time. Best Regards, Keisuke Kuroda NTT Comware