3

嗨，我托管在 Heroku 上，在他们的 Ika 计划（7,5gb ram）上运行 postgresql 9.1.6。我有一张叫汽车的桌子。我需要执行以下操作：

SELECT COUNT(*) FROM "cars" WHERE "cars"."reference_id" = 'toyota_hilux'

现在这需要很长时间（64 秒！！！）

Aggregate  (cost=2849.52..2849.52 rows=1 width=0) (actual time=63388.390..63388.391 rows=1 loops=1)
  ->  Bitmap Heap Scan on cars  (cost=24.76..2848.78 rows=1464 width=0) (actual time=1169.581..63387.361 rows=739 loops=1)
        Recheck Cond: ((reference_id)::text = 'toyota_hilux'::text)
        ->  Bitmap Index Scan on index_cars_on_reference_id  (cost=0.00..24.69 rows=1464 width=0) (actual time=547.530..547.530 rows=832 loops=1)
              Index Cond: ((reference_id)::text = 'toyota_hilux'::text)
Total runtime: 64112.412 ms

一点背景：

该表包含大约 3.2m 行，我试图依靠的列具有以下设置：

reference_id character varying(50);

和索引：

CREATE INDEX index_cars_on_reference_id
  ON cars
  USING btree
  (reference_id COLLATE pg_catalog."default" );

我究竟做错了什么？我希望这种表现不是我应该期待的——或者我应该期待吗？

4

1 回答 1

5

@Satya在他的评论中声称的并不完全正确。在存在匹配索引的情况下，如果表统计信息表明它会返回超过大约 5%（取决于）表，则计划程序仅选择全表扫描，因为这样扫描整个表会更快。

正如您从自己的问题中看到的那样，您的查询并非如此。它使用Bitmap Index Scan后跟Bitmap Heap Scan。虽然我本来期望一个普通的索引扫描。（？）

我在您的解释输出中注意到另外两件事：
第一次扫描找到 832 行，而第二次将计数减少到 739。这表明您的索引中有许多死元组。

检查每个步骤后的执行时间，EXPLAIN ANALYZE并可能将结果添加到您的问题中：

首先，使用 EXPLAIN ANALYZE 重新运行查询两到三次以填充缓存。与第一次相比，最后一次运行的结果是什么？

下一个：

VACUUM ANALYZE cars;

重新运行。

如果你在表上有很多写操作，我会设置一个低于 100 的填充因子。比如：

ALTER TABLE cars SET (fillfactor=90);

如果您的行大小很大或者您有很多写操作，请降低。然后：

VACUUM FULL ANALYZE cars;

这需要一段时间。重新运行。

或者，如果您有能力这样做（并且其他重要查询没有相互矛盾的要求）：

CLUSTER cars USING index_cars_on_reference_id;

这会按照索引的物理顺序重写表，这应该会使这种查询更快。

规范化架构

如果您需要非常快，请创建一个car_type带有serial主键的表并从表中引用它cars。这会将必要的索引缩小到现在的一小部分。

不用说，在您尝试任何这些之前先进行备份。

CREATE temp TABLE car_type (
   car_type_id serial PRIMARY KEY
 , car_type text
 );

INSERT INTO car_type (car_type)
SELECT DISTINCT car_type_id FROM cars ORDER BY car_type_id;

ANALYZE car_type;

CREATE UNIQUE INDEX car_type_uni_idx ON car_type (car_type); -- unique types

ALTER TABLE cars RENAME COLUMN car_type_id TO car_type; -- rename old col
ALTER TABLE cars ADD COLUMN car_type_id int; -- add new int col

UPDATE cars c
SET car_type_id = ct.car_type_id
FROM car_type ct
WHERE ct.car_type = c.car_type;

ALTER TABLE cars DROP COLUMN car_type; -- drop old varchar col

CREATE INDEX cars_car_type_id_idx ON cars (car_type_id);    

ALTER TABLE cars 
ADD CONSTRAINT cars_car_type_id_fkey FOREIGN KEY (car_type_id )
REFERENCES car_type (car_type_id) ON UPDATE CASCADE; -- add fk

VACUUM FULL ANALYZE cars;

或者，如果你想全力以赴：

CLUSTER cars USING cars_car_type_id_idx;

您的查询现在看起来像这样：

SELECT count(*)
FROM   cars
WHERE  car_type_id = (SELECT car_type_id FROM car_type
                      WHERE car_type = 'toyota_hilux')

并且应该更快。主要是因为现在index和table变小了，也因为integerhandling比varcharhandling快。但是，与列上的聚簇表相比，增益不会显着varchar。

一个受欢迎的副作用：如果你必须重命名一个类型，它UPDATE现在只有一行，根本不会弄乱大表。

于 2012-10-22T16:10:24.473 回答