| From: | 章晨曦 <zhangchenxi(at)halodbtech(dot)com> |
|---|---|
| To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
| Cc: | David G(dot) Johnston <david(dot)g(dot)johnston(at)gmail(dot)com>, pgsql-hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org> |
| Subject: | Re: Performance issue on temporary relations |
| Date: | 2025-08-19 18:13:01 |
| Message-ID: | tencent_3B2E5A5E6CCB7900226AB9B5@qq.com |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
> BTW, it appears to me that doing it this way is O(N^2) in the number
> of active temp tables. So it's not hard to believe that the patch
> as-presented would actually be a fairly serious performance drag for
> some use cases with lots of temp tables. There are certainly ways
> we could do better than that (hash table, bloom filter, etc) but
> there would be even more engineering effort needed.
Yes, you're right. I also consider using like hash table to do more better and try
to merge the in_use list and on_commits list into one hashtable. But, as just you
said, it needs much more effort. Thanks any way.
Regards,
Jet
Halo Tech (www.halodbtech.com)
openHalo (www.openhalo.org)
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Nathan Bossart | 2025-08-19 18:21:12 | Re: Proper object locking for GRANT/REVOKE |
| Previous Message | Tom Lane | 2025-08-19 18:08:19 | Re: VM corruption on standby |