> 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 bette
"=?utf-8?B?56ug5pmo5pum?=" writes:
> Yes. ON COMMIT DELETE temp table will be truncated at every commit.
> But if we can control that only accessed temp tables will be truncated
> may be better. When an temp tables accessed, it will be stored in in_use
> list, and when on commit, it will check the
> [ shrug... ] If you create an ON COMMIT DELETE temp table, you
> are explicitly asking for a truncation to happen at every commit.
> I don't think you have much room to beef about the fact that one
> happens.
Yes. ON COMMIT DELETE temp table will be truncated at every commit.
But if we can cont
"=?utf-8?B?56ug5pmo5pum?=" writes:
> I agree the application is not well designed for PostgreSQL because it was
> migrated
> from Oracle, and may not do such optimization. But back to this issue, even
> though
> we only create 10 temporary relations, it will cause 10 truncates on every
> transa
>> 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 justificatio
"David G. Johnston" writes:
> On Tue, Aug 19, 2025 at 8:45 AM 章晨曦 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 everyon
On Tue, Aug 19, 2025 at 8:45 AM 章晨曦 wrote:
> > I do not think this is something we ought to consider. It might help
> > certain corner use-cases, but it's probably a net loss for most.
> > In particular, I don't think that creating thousands of temp tables in
> > a session but then touching only
> I do not think this is something we ought to consider. It might help
> certain corner use-cases, but it's probably a net loss for most.
> In particular, I don't think that creating thousands of temp tables in
> a session but then touching only a few of them in any one transaction
> is a very pla
"=?utf-8?B?56ug5pmo5pum?=" writes:
> Recently I noticed a performance issue on temporary relation. The issue will
> happened on
> ON COMMIT DELETE temporary relations. If one session only create a few
> temporary relations,
> well, it's fine. But if one session creates plenty of ON COMMIT DELETE
