From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | "David G(dot) Johnston" <david(dot)g(dot)johnston(at)gmail(dot)com> |
Cc: | 章晨曦 <zhangchenxi(at)halodbtech(dot)com>, pgsql-hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org> |
Subject: | Re: Performance issue on temporary relations |
Date: | 2025-08-19 16:02:39 |
Message-ID: | 585869.1755619359@sss.pgh.pa.us |
Views: | Whole Thread | Raw Message | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
"David G. Johnston" <david(dot)g(dot)johnston(at)gmail(dot)com> writes:
> On Tue, Aug 19, 2025 at 8:45 AM 章晨曦 <zhangchenxi(at)halodbtech(dot)com> wrote:
>> Acturely, we just facing such problem in some real systems. More than 3,700
>> temporary tables created! I accept such case is not that common, but it
>> does exist.
> It is unfair to add a performance penalty to everyone just because some
> people write bad code. I concur that adding complexity to the system to
> gracefully handle this corner-case doesn't seem justified. A use case
> description, not mere existence, is needed to provide such justification.
Yeah, the real sub-text here is "should we believe that this
application is well designed?". It sounds like a fairly brute-force
solution.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Yura Sokolov | 2025-08-19 16:16:39 | Re: VM corruption on standby |
Previous Message | Tom Lane | 2025-08-19 15:56:41 | Re: When deleting the plpgsql function, release the CachedPlan of the function |