> It seems that in your patch, WAL logging is skipped for all tables, not just
> temporary tables.
This code path is only used in two cases though:
* For the temporary tables ON COMMIT DROP
* For truncating tables that were created in the same transaction, or which
were already truncated in the
Hi Floris,
> On Jul 18, 2024, at 21:36, Floris Van Nee wrote:
>
>
>> I also encountered the similar performance issue with temporary tables
>> andprovided a patch to optimize the truncate performance during commit
>> in [1].
>
> Interesting, that is definitely another good way to improve the p
> I also encountered the similar performance issue with temporary tables
> andprovided a patch to optimize the truncate performance during commit
> in [1].
Interesting, that is definitely another good way to improve the performance,
especially with a large number of temp tables. I think the two o
Hi Floris,
> On Jul 16, 2024, at 19:47, Floris Van Nee wrote:
>
> Hi hackers,
>
> I'm looking for some input on an issue I've observed. A common pattern
> I've seen is using temporary tables to put data in before updating the
> real tables. Something roughly like:
>
> On session start:
> CREAT
>
> I didn't investigate your particular issue but generally speaking creating a
> table, even a temporary one, is an expensive operation.
>
> Note that it's far from being a seperate file on the disk. It affects catalog
> tables, shared buffers, all the corresponding locks, etc. If you have ind
Hi,
> I'm looking for some input on an issue I've observed. A common pattern
> I've seen is using temporary tables to put data in before updating the
> real tables. Something roughly like:
>
> On session start:
> CREATE TEMP TABLE temp_t1 (...) ON COMMIT DELETE ROWS;
>
> On update:
> BEGIN;
> COPY
