TE
科技回声
首页24小时热榜最新最佳问答展示工作
GitHubTwitter
首页

科技回声

基于 Next.js 构建的科技新闻平台,提供全球科技新闻和讨论内容。

GitHubTwitter

首页

首页最新最佳问答展示工作

资源链接

HackerNews API原版 HackerNewsNext.js

© 2025 科技回声. 版权所有。

Mishaps in Redshift Temporary Tables

12 点作者 sschnei8大约 1 年前

1 comment

Max-Ganz-II大约 1 年前
1. Temp tables are a bad idea, last I knew, because they increase the amount of data in the system tables (every time you create a temp table, you create records for it, it&#x27;s MVCC, so they don&#x27;t go away until VACUUMed) and system table bloat has been a serious problem for Redshift, since it seems only to go away on reboot. With a client now, lots of tables, takes 60 seconds to issue a system command. A previous client had to reboot daily. I simply advise clients not to use them.<p>2. Temp tables do not participate in k-safety, so you avoid that performance cost.<p>3. I suspect I&#x27;ve seen something odd happening with compression with temp tables. I&#x27;ve not investigated.<p>4. Using `CREATE TABLE AS` is, for me, verboten. Absolutely forbidden. This is because Redshift selects column encodings, and does a very, very poor job of doing so. Never let Redshift select column encodings (or sort keys, or distribution keys, or rely on auto-vacuum, or auto-analyze, and above all, never use AutoWLM).
评论 #40299970 未加载