标签: size

我有一个 PostgreSQL 表。select *很慢，但又select id好又快。我认为可能是行的大小非常大并且需要一段时间来运输，或者可能是其他一些因素。

我需要所有字段（或几乎所有字段），因此仅选择一个子集不是一个快速解决方案。选择我想要的字段仍然很慢。

这是我的表架构减去名称：

integer                  | not null default nextval('core_page_id_seq'::regclass)
character varying(255)   | not null
character varying(64)    | not null
text                     | default '{}'::text
character varying(255)   | 
integer                  | not null default 0
text                     | default '{}'::text
text                     | 
timestamp with time zone | 
integer                  | 
timestamp with time zone | 
integer                  | 

文本字段的大小可以是任意大小。但是，在最坏的情况下，不会超过几千字节。

问题

1. 有什么关于这叫“疯狂低效”的吗？
2. 有没有办法在 Postgres 命令行中测量页面大小来帮助我调试？

在 PostgreSQL 和 SQL Server 中，默认页面大小为 8 KB，在 MySQL 中为 16 KB，在 IBM DB2 和 Oracle 中仅为 4 KB。

为什么这些页面尺寸如此之小？

是否有历史或内存使用原因？

在 DB2 中，我有一个包含大型二进制数据的表。现在我清除了整个表并运行了 runstats、reorg、runstats，但是占用的磁盘空间量没有改变。这里可能有什么问题？

该表位于我创建的自己的表空间中，如下所示：

CREATE BUFFERPOOL "MY_BP" SIZE 250 AUTOMATIC PAGESIZE 4096;
CREATE LARGE TABLESPACE MY_TBS IN DATABASE PARTITION GROUP IBMDEFAULTGROUP PAGESIZE 4096 MANAGED BY AUTOMATIC STORAGE EXTENTSIZE 64 PREFETCHSIZE 64 BUFFERPOOL MY_BP OVERHEAD 10.500000 TRANSFERRATE 0.140000 FILE SYSTEM CACHING;

我删除/重组如下：

DELETE FROM MY_TBL
RUNSTATS ON TABLE MY_TBL WITH DISTRIBUTION AND DETAILED INDEXES ALL
REORG TABLE MY_TBL
RUNSTATS ON TABLE MY_TABLE WITH DISTRIBUTION AND DETAILED INDEXES ALL
ALTER TABLESPACE MY_TBS REDUCE

表 MY_TBL 在所有这些之前占用了 2.5GB，在删除/重组之后它只使用了3MB。

FWIW：我正在运行 DB2/NT …

在 Dynamics AX 中有一个缓存机制，可以将表配置为加载到内存中并缓存。此缓存限制为一定数量的 KB，以防止出现内存问题。我正在谈论的设置被调用entiretablecache并在请求单个记录时将整个表加载到内存中。

直到最近，我们依靠一些脚本来验证具有此设置的表的大小，以查看表大小是否高于此限制。

然而，现在，压缩开始发挥作用，诸如sp_spaceused或sys.allocation_units 之类的东西似乎报告了压缩数据实际使用的空间。

显然，应用程序服务器正在处理未压​​缩的数据，因此 SQL Server 中磁盘上的数据大小无关紧要。我需要未压缩数据的实际大小。

我知道sp_estimate_data_compression_savings但正如名字所说，这只是一个估计。
我希望尺寸尽可能正确。

我能想到的唯一方法是一些复杂的动态 SQL 创建与压缩表具有相同结构的未压缩表，将压缩数据插入到影子表中，然后检查影子表的大小。
不用说，这有点乏味，在数百 GB 的数据库上运行需要一段时间。

Powershell 可能是一个选项，但我不想遍历所有表以select *对它们执行 a以检查脚本中的大小，因为这只会淹没缓存并且可能需要很长时间。

简而言之，如果可能的话，我需要一种方法来获取每个表的大小，因为它一旦被解压缩，并且在呈现给应用程序的等式中会出现碎片。我对不同的方法持开放态度，首选 T-SQL，但我不反对 Powershell 或其他创造性方法。

假设应用程序中的缓冲区是数据的大小。bigint 始终是 bigint 的大小，而字符数据类型是每个字符 2 个字节（unicode）。BLOB 数据也占用数据的大小，枚举基本上是一个整数，数字数据是 numeric(38,12)，datetime 是日期时间的大小。此外，没有NULL值，它们要么存储为空字符串，要么存储1900-01-01为零。

没有关于如何实现的文档，但这些假设基于一些测试以及 PFE 和支持团队使用的脚本（显然也忽略了压缩，因为检查是在应用程序中构建的，而应用程序无法分辨）如果底层数据被压缩），它还检查表大小。例如，此链接指出：

避免对大型表使用 EntireTable 缓存（在 AX 2009 中超过 128 KB 或 16 页，在 AX 2012 中超过“整个表缓存大小”应用程序设置[默认值：32KB 或 4 页]）——改为使用记录缓存。

我正在尝试为包含多个索引列的 SQLite DB 估计数据库大小（在磁盘上）。这些列是（SQLite）类型的整数和字符串。用这些列估计每行的大小很简单，但我不确定如何考虑由于索引而产生的额外的每行填充。最好的方法是什么？

我最近作为 DBA 实习生开始使用 SQL Server 2008。我需要计算数据库的大小，还要估计它最近几个月的增长以及未来 12 个月的预测增长。

我可以使用 sp_spaceused 语句来计算实际大小，但如何计算其他所有内容？

考虑 Postgres 9.4 中的下表：

CREATE TABLE t
(
  a1 bigserial,
  a2 bigint NOT NULL,
  a3 bigint NOT NULL,
  a4 integer, 
  a5 timestamp with time zone NOT NULL,
  a6 timestamp with time zone NOT NULL DEFAULT now(),
  a7 bigint NOT NULL,
  a8 bigint NOT NULL,
  a9 real,
  a10 integer,

  CONSTRAINT kkkey PRIMARY KEY (a1)
)

保存这张表的估计成本是多少？

创纪录的成本：

size(bigserial) 
+ size(bigint) 
+ size(bigint) 
+ size(integer) 
+ size(timestamp) 
+ size(timestamp) 
+ size(bigint) 
+ size(bigint) 
+ size(real) 
+ size(integer)
= 8 + 8 + …

我们一再看到尝试索引值超过最大大小的列失败。Postgres 10 有这样的错误信息：

ERROR:  index row size xxxx exceeds maximum 2712 for index "foo_idx"
HINT:  Values larger than 1/3 of a buffer page cannot be indexed.
       Consider a function index of an MD5 hash of the value, or use full text indexing.

Run Code Online (Sandbox Code Playgroud)

例子：

• 字符可变索引开销和长度限制
• 索引最大行大小错误

等等。

现在，a_horse_with_no_name 演示了一个具有更大text值（10000 个字符）的案例，它似乎仍然适用UNIQUE于 Postgres 9.6 中的索引。引用他的测试用例：

create table tbl (col text);
create unique index on tbl (col);

insert into tbl
values (rpad(md5(random()::text), 10000, md5(random()::text)));

select length(val) …

这个答案促使我再次思考我的下表，但我仍然不确定如何存储来自数据分析的变量/结果以便在后处理中快速选择。如果存储，我认为它使用部分索引（B 树）做得很好，因为在我这里描述的应用程序中只需要一个数据子集。假设您有三个标准正交表：measurement、events和headers，其中都有一些静态（以字节为单位的事件大小等）列，但想知道从数据分析中存储一些数字是否有益。

没有名称的表模式测量示例：

SERIAL                     | NOT NULL
INTEGER                    | NOT NULL
INTEGER                    | NOT NULL
TIMESTAMP WITH TIME ZONE   | DEFAULT CURRENT_TIMESTAMP

由于我需要统计数据，我担心通过 INTEGER 字段增加架构大小。我不想将很少使用的变量存储在主表中。我不希望我的索引没有像PostgreSQL Up & Running和这篇文章中描述的那样被使用，为什么我的索引没有被索引？

可能的来源

• Gordon Linoff和他的博客在这里

什么时候应该将静态/动态统计信息存储在表中？PostgreSQL 的部分索引中如何高效地存储静态/动态统计信息？

我在我的 Django 1.4.8 项目中通过 PgBouncer 1.4.2 使用 PostgreSQL 9.1.6。django_session表一直在增长。VACUUM 没有帮助。VACUUM FULL 运行数小时。TRUNCATE通常只帮助。

该表包含大约 10KB 的行。每秒更新 40 次。

# SELECT table_name, pg_size_pretty(table_size) AS table_size, pg_size_pretty(indexes_size) AS indexes_size, pg_size_pretty(total_size) AS total_size
FROM (
    SELECT table_name, pg_table_size(table_name) AS table_size, pg_indexes_size(table_name) AS indexes_size, pg_total_relation_size(table_name) AS total_size
    FROM (
        SELECT ('"' || table_schema || '"."' || table_name || '"') AS table_name
        FROM information_schema.tables
    ) AS all_tables ORDER BY total_size DESC LIMIT 1
) AS pretty_sizes;
        table_name         | table_size | indexes_size | …