Re: Performance issue on temporary relations

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

In response to

Responses

Browse pgsql-hackers by date

  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