Re: Optimize commit performance with a large number of 'on commit delete rows' temp tables - Mailing list pgsql-hackers

From wenhui qiu
Subject Re: Optimize commit performance with a large number of 'on commit delete rows' temp tables
Date
Msg-id CAGjGUAKp6H4E6GnfpVGsfD3=9fm++2nAHaKMnb-6NDTFOWFsCQ@mail.gmail.com
Whole thread Raw
In response to Re: Optimize commit performance with a large number of 'on commit delete rows' temp tables  ("feichanghong" <feichanghong@qq.com>)
Responses Re: Optimize commit performance with a large number of 'on commit delete rows' temp tables
List pgsql-hackers
Hi feichanghong
     Thanks for updating the patch ,I think could be configured as a GUC parameter,PostgreSQL has too many static variables that are written to death and explicitly stated in the code comments may later be designed as parameters. Now that more and more applications that previously used oracle are migrating to postgresql, there will be more and more scenarios where temporary tables are heavily used.Because oracle will global temporary tablespace optimised for this business scenario, which works well in oracle, migrating to pg faces very tricky performance issues,I'm sure the patch has vaule

Best Regards

feichanghong <feichanghong@qq.com> 于2024年7月6日周六 03:40写道:
The patch in the attachment, compared to the previous one, adds a threshold for
using the bloom filter. The current ON_COMMITS_FILTER_THRESHOLD is set to 64,
which may not be the optimal value. Perhaps this threshold could be configured
as a GUC parameter?

Best Regards,
Fei Changhong

pgsql-hackers by date:

Previous
From: Andrew Dunstan
Date:
Subject: Re: 010_pg_basebackup.pl vs multiple filesystems
Next
From: Bryan Green
Date:
Subject: Re: Simplifying width_bucket_numeric()