我正在尝试将 PostgreSQL 扩展为索引位串最多 1000 位。（这些位串是通过量化高维向量创建的，因此每个维度最多分配 4 位）。插入很少见，而搜索是最常用的操作。在搜索中，我想获取与位字符串完全匹配的所有行。
对于 GIN 来说，这看起来是一个完美的工作（结合我自己的数据类型），或者你怎么看？
postgresql performance index index-tuning postgresql-performance
我有下表，大约有 175k 条记录：
Column | Type | Modifiers
----------------+-----------------------------+-------------------------------------
id | uuid | not null default uuid_generate_v4()
competition_id | uuid | not null
user_id | uuid | not null
first_name | character varying(255) | not null
last_name | character varying(255) | not null
image | character varying(255) |
country | character varying(255) |
slug | character varying(255) | not null
total_votes | integer | not null default 0
created_at | timestamp without time zone |
updated_at | timestamp without time …postgresql performance index-tuning window-functions rank query-performance
我正在进入我的神秘查询的下一个级别。看起来在一个存在的内部有一个子选择，但在同一个表上。我认为这可能可以通过INNER JOIN更高的方式简化。
使用 PostgreSQL 9.4.2。
表定义 ( /d+)：https : //gist.github.com/neezer/879f5d3649ca1903c6f3
基数：
billing_pricequote: 1,462,625 行
billing_pricequotestatus: 3,331,657 行
billing_lineitem: 43,687,855 行
这是原始查询，不建议对里面的子EXISTS查询进行修改：
SELECT i.quote_id, i.acct_id AS account_id, SUM(i.delta_amount) AS amt
FROM billing_lineitem i
INNER JOIN billing_pricequote pq ON i.quote_id = pq.id
WHERE pq.date_applied AT TIME ZONE 'PST' BETWEEN '2016-02-02T00:00:00'::timestamp
AND '2016-03-03T22:27:41.734102-08:00'::timestamptz
AND EXISTS(
SELECT s1.quote_id
FROM billing_pricequotestatus s1
INNER JOIN (
SELECT DISTINCT ON (quote_id) quote_id, MAX(created_at) AS max_created_at …postgresql performance timestamp greatest-n-per-group postgresql-performance
CREATE TABLE test_table
(
id uuid NOT NULL,
"RefId" uuid NOT NULL,
"timestampCol" timestamp without time zone NOT NULL,
"bigint1" bigint NOT NULL,
"bigint2" bigint NOT NULL,
"int1" integer NOT NULL,
"int2" integer NOT NULL,
"bigint3" bigint NOT NULL,
"bigint4" bigint NOT NULL,
"bigint5" bigint NOT NULL,
"hugeText" text NOT NULL,
"bigint6" bigint NOT NULL,
"bigint7" bigint NOT NULL,
"bigint8" bigint NOT NULL,
"denormalizedData" jsonb NOT NULL,
"textCol" text NOT NULL,
"smallText" text NOT NULL,
"createdAt" timestamp with time zone …smallint类型和bool存储布尔值的类型有什么区别？
这个问题出现在对地理信息系统堆栈交换问题的评论中。
我在 BRIN 索引的 OLAP 查询中发现了许多用例，因为它们要小得多，并且速度与 BTREE 索引处于同一数量级。
通常，我使用 BRIN 索引来单调（或接近）增加时间戳列。在我们的 OLTP 数据库中，它们紧密地放置在磁盘上，因为随着时间的推移，它们自然会按顺序写入。
在我们的仓储 Postgres 实例中，表的某些部分是大批量加载的，不一定按时间排序。
是否有一些分析查询可以告诉我数据是否放置得太随机而无法使用 BRIN，即使列值分布似乎应该遵循创建 BRIN 索引的所有先决条件？
我们使用 Postgres 进行分析（星型模式）。每隔几秒钟，我们就会收到大约 500 种指标类型的报告。最简单的模式是：
timestamp metric_type value
78930890 FOO 80.9
78930890 ZOO 20
我们的 DBA 提出了一个建议，将所有相同 5 秒的报告展平为：
timestamp metric1 metric2 ... metric500
78930890 90.9 20 ...
一些开发人员反驳这种说法，称这增加了开发的巨大复杂性（批处理数据，以便一次性编写）和可维护性（仅查看表或添加字段更复杂）。
DBA 模型是此类系统中的标准做法还是仅在原始模型显然不够可扩展时的最后手段？
编辑：最终目标是为用户绘制折线图。因此，查询主要是选择几个指标，按小时/分钟折叠它们，然后选择每小时（或任何其他时间段）的最小值/最大值/平均值。
编辑：DBA 的主要论点是将行数减少 x500 次将允许更高效的索引和内存（在此优化之前，该表将包含数亿行）。然后在选择多个度量标准时，建议的架构将允许一个通过数据而不是每个度量的单独索引搜索。
编辑：500 个指标是一个“上限”，但实际上大部分时间每 5 秒只报告约 40 个指标（虽然不是相同的 40）
我们注意到最近几周我们平台的性能下降，所以我运行了以下命令：
select relname, last_vacuum, last_autovacuum, last_analyze, last_autoanalyze
from pg_stat_user_tables
where relname like 'core_%';
并注意到我们的主桌已经一个多星期没有自动清扫了。所以上周我跑了：
vacuum analyse verbose TABLENAME
这似乎有帮助，但我们现在又遇到了同样的问题。仔细检查后，很多表要么从未被分析过（自动或其他方式），除了vacuum analyse上周手动运行之外，没有一个表被手动清理过，而且很多其他表也没有被自动清理过，充其量是几天前，更糟的是几周前。
我对条款的理解如下：
在 中postgres.conf，autovacuum 属性被注释掉了，但是文档指出这是默认打开的，所以我的假设是即使它被注释掉了，它仍然应该打开吗？
有人可以解释为什么这些表不会被频繁地清理和分析，更具体地说，这些没有更新的值实际上对系统有那么大的影响吗？
信息：Postgres 9.1 操作系统：Ubuntu 12.04
输出
SELECT relname as "Table",
pg_size_pretty(pg_total_relation_size(relid)) As "Size",
pg_size_pretty(pg_total_relation_size(relid) - pg_relation_size(relid)) as "External Size"
FROM pg_catalog.pg_statio_user_tables
ORDER BY pg_total_relation_size(relid) DESC;
Table | Size | External Size
-----------------+------+---------------
"Primary Table" | 27G | 8232M
postgresql performance postgresql-9.1 postgresql-performance
我使用的是 Postgres 9.3.4，我有 4 个查询，它们的输入非常相似，但响应时间却大不相同：
EXPLAIN ANALYZE SELECT posts.* FROM posts
WHERE posts.source_id IN (19082, 19075, 20705, 18328, 19110, 24965, 18329, 27600, 17804, 20717, 27598, 27599)
AND posts.deleted_at IS NULL
ORDER BY external_created_at desc
LIMIT 100 OFFSET 0;
QUERY PLAN
----------------------------------------------------------------------------------------------------------------------------------------------------------------------------
Limit (cost=0.43..585.44 rows=100 width=1041) (actual time=326092.852..507360.199 rows=100 loops=1)
-> Index Scan using index_posts_on_external_created_at on posts (cost=0.43..14871916.35 rows=2542166 width=1041) (actual time=326092.301..507359.524 rows=100 loops=1)
Filter: (source_id = ANY ('{19082,19075,20705,18328,19110,24965,18329,27600,17804,20717,27598,27599}'::integer[]))
Rows Removed by Filter: 6913925
Total runtime: 507361.944 ms
EXPLAIN …postgresql performance index optimization postgresql-9.3 postgresql-performance
我有一个表，其中包含一些基于其他表的预先计算的数据。（考虑到我必须处理的数据大小，动态计算的计算成本太高。）随着源数据的添加，我将逐步生成。（UPDATE在正常使用中我永远不需要它；部分可能会被删除和重新生成。）该表将相当大。它目前大约有 5000 万行，并且每年都会增长。
对该表的大多数查询都将通过外键 ID 列进行过滤。因此，如果该 ID 的所有行都分组到相同的页面中，它们的性能会更好。我可以通过创建索引和CLUSTER定期调用来保证磁盘上的这种排序，但这显然不太理想，因为它需要某种计划任务，根据使用情况和其他计划任务进行协调等。
但是，由于我以与我想要使用的外键相关的块的形式生成这些数据CLUSTER，因此我可以轻松地ORDER BY在INSERT命令中添加一个子句：
INSERT INTO big_table (source_table1_id,a,b,c)
SELECT
source_table1_id,
5 /* some formula */,
/* ... */
FROM source_table1
JOIN source_table2 ON ...
...
WHERE ... /* some condition indicating what needs to be generated */
ORDER BY source_table1_id
这是否会影响磁盘存储顺序，将行分组为接近最小页数？如果确实如此，是否还有其他进程可能会在以后弄乱磁盘顺序？
我目前正在使用 PostgreSQL 9.3，但我想了解更新的版本以及升级。
postgresql ×10
performance ×7
index ×3
index-tuning ×3
optimization ×3
datatypes ×1
rank ×1
star-schema ×1
timestamp ×1