假设我有一个包含字段A和的表B。我在A+上进行常规查询B，所以我在 上创建了一个复合索引(A,B)。A复合索引是否也会对查询进行全面优化？
此外，我在 上创建了一个索引A，但 Postgres 仍然只使用复合索引来查询A。如果前面的答案是肯定的，我想这并不重要，但是为什么它默认选择复合索引，如果单个A索引可用？
我们的系统写入了大量数据（一种大数据系统）。写入性能足以满足我们的需求，但读取性能真的太慢了。
我们所有表的主键（约束）结构都相似：
timestamp(Timestamp) ; index(smallint) ; key(integer).
一个表可以有数百万行，甚至数十亿行，而一个读请求通常是针对特定时间段（时间戳/索引）和标记的。查询返回大约 20 万行是很常见的。目前，我们每秒可以读取大约 15k 行，但我们需要快 10 倍。这是可能的，如果是，如何？
注意： PostgreSQL 是和我们的软件一起打包的，所以不同客户端的硬件是不一样的。
它是一个用于测试的虚拟机。VM 的主机是具有 24.0 GB RAM 的 Windows Server 2008 R2 x64。
Server 2008 R2 x64
2.00 GB of memory
Intel Xeon W3520 @ 2.67GHz (2 cores)
postgresql.conf 优化shared_buffers = 512MB (default: 32MB)
effective_cache_size = 1024MB (default: 128MB)
checkpoint_segment = 32 (default: 3)
checkpoint_completion_target = 0.9 (default: 0.5)
default_statistics_target = 1000 (default: 100)
work_mem = 100MB (default: 1MB)
maintainance_work_mem = 256MB …我正在尝试确定哪些索引用于带有WHERE条件的 SQL 查询，GROUP BY而当前运行速度很慢。
我的查询：
SELECT group_id
FROM counter
WHERE ts between timestamp '2014-03-02 00:00:00.0' and timestamp '2014-03-05 12:00:00.0'
GROUP BY group_id
该表目前有 32.000.000 行。当我增加时间范围时，查询的执行时间会增加很多。
有问题的表如下所示：
CREATE TABLE counter (
id bigserial PRIMARY KEY
, ts timestamp NOT NULL
, group_id bigint NOT NULL
);
我目前有以下索引，但性能仍然很慢：
CREATE INDEX ts_index
ON counter
USING btree
(ts);
CREATE INDEX group_id_index
ON counter
USING btree
(group_id);
CREATE INDEX comp_1_index
ON counter
USING btree
(ts, group_id);
CREATE INDEX comp_2_index
ON counter …postgresql performance index optimization postgresql-9.3 query-performance
我有一个基于日期字段和数字字段的订单查询 Postgres 中的表，该表有 1000000 条记录
表的数据类型为：
fcv_id = serial
fcv_fecha_comprobante = timestamp without time zone
fcv_numero_comprobante = varchar(60)
查询是：
SELECT fcv_id, fcv_fecha_comprobante FROM factura_venta
ORDER BY fcv_fecha_comprobante, fcv_numero_comprobante
这个查询大约需要 5 秒，但如果我取出“order by”，查询只需要 0.499 秒
我遇到的问题是我需要在尽可能短的时间内运行这个查询，所以我在谷歌上搜索我可以做什么并使用以下查询创建一个复合索引
CREATE INDEX factura_venta_orden ON factura_venta
USING btree (fcv_fecha_comprobante ASC NULLS LAST
, fcv_numero_comprobante ASC NULLS LAST);
ALTER TABLE factura_venta CLUSTER ON factura_venta_orden;
但是查询花费的时间相同甚至更多。
我使用的是 Postgres 9.0.13，这里是 73436 行的 EXPLAIN
Sort (cost=11714.03..11897.62 rows=73436 width=27) (actual time=1260.759..1579.853 rows=73436 loops=1)
Sort Key: fcv_fecha_comprobante, fcv_numero_comprobante
Sort Method: external merge …