The Dangers of Temporary Tables | Scaling Postgres 349

[@RU-qv3jl]

Get well soon, thanks for being such a hard worker to get the show out.

[@kevinshah_tv]

Take care Creston, wishing you recover full and recover fast.

[@berndeckenfels]

Get well soon and remember to take recovery slowly

[@jaimeduncan6167]

Thanks, I hope you get well soon.

[@utenatenjou2139]

Get well soon. The unlogged table is interesting, thanks.

[@rosendo3219]

get well soon Creston!

[@dileepn2479]

Have a speed recovery sir

[@RU-qv3jl]

You‘re right about SQL Server to a degree. You can choose if your temp tables are session scoped or global. However, they don‘t chew through something like OIDs. I was also thinking about unclogged table and a sequence so that each session can use the table uniquely to its session and then clean up after itself. Just a though, maybe a bad one. I mainly use SQL Server and am interested in PostreSQL to get away from all the license fees. Just a bit more planning first :)

[@alexisfibonacci]

SQL Server has two types of temporary tables. There are those that are session bound and those that remain till the server is restarted. For the session bound tables, the issues will be the same. Even though you reference a session-bound temporary table as #temp_table, it gets created in the tempdb with some "calculated name" and that can definitely lead to bloat.

[@anttilinno3660]

When did the Covid become the Voldemort - the name that you cannot utter? Also, piggy using native package manager. Good luck in debian, where packages are years old :)