Re: Optimize commit performance with a large number of 'on commit delete rows' temp tables

From: wenhui qiu <qiuwenhuifx(at)gmail(dot)com>
To: feichanghong <feichanghong(at)qq(dot)com>
Cc: pgsql-hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>
Subject: Re: Optimize commit performance with a large number of 'on commit delete rows' temp tables
Date: 2024-07-07 13:32:24
Message-ID: CAGjGUAKp6H4E6GnfpVGsfD3=9fm++2nAHaKMnb-6NDTFOWFsCQ@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: 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(at)qq(dot)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
>

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Bryan Green 2024-07-07 13:44:56 Re: Simplifying width_bucket_numeric()
Previous Message Andrew Dunstan 2024-07-07 13:10:48 Re: 010_pg_basebackup.pl vs multiple filesystems