我有一个 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 |
Run Code Online (Sandbox Code Playgroud)
文本字段的大小可以是任意大小。但是,在最坏的情况下,不会超过几千字节。
postgresql performance size disk-space postgresql-performance
VACUUM ANALYZE VERBOSE
在对一些较大的表进行重大DELETE/INSERT
更改后,我们会在它们上运行“手册” 。这似乎没有问题,尽管有时表的VACUUM
工作会运行数小时(有关类似问题和推理,请参阅此帖子)。
在进行更多研究后,我发现即使在运行VACUUM
. 例如,以下是此响应中查询生成的一些统计信息。
-[ RECORD 50 ]--+---------------------------
relname | example_a
last_vacuum | 2014-09-23 01:43
last_autovacuum | 2014-08-01 01:19
n_tup | 199,169,568
dead_tup | 111,048,906
av_threshold | 39,833,964
expect_av | *
-[ RECORD 51 ]--+---------------------------
relname | example_b
last_vacuum | 2014-09-23 01:48
last_autovacuum | 2014-08-30 12:40
n_tup | 216,596,624
dead_tup | 117,224,220
av_threshold | 43,319,375
expect_av | *
-[ RECORD 52 ]--+---------------------------
relname | example_c
last_vacuum | …
Run Code Online (Sandbox Code Playgroud) 就像另一个问题所示,我在 3D 空间中处理了很多(> 10,000,000)个点条目。这些点定义如下:
CREATE TYPE float3d AS (
x real,
y real,
z real);
Run Code Online (Sandbox Code Playgroud)
如果我没记错的话,需要 3*8 字节 + 8 字节填充(MAXALIGN
是 8)来存储这些点之一。有没有更好的方法来存储这种数据?在前面提到的问题中,有人指出复合类型涉及相当多的开销。
我经常做这样的空间查询:
SELECT t1.id, t1.parent_id, (t1.location).x, (t1.location).y, (t1.location).z,
t1.confidence, t1.radius, t1.skeleton_id, t1.user_id,
t2.id, t2.parent_id, (t2.location).x, (t2.location).y, (t2.location).z,
t2.confidence, t2.radius, t2.skeleton_id, t2.user_id
FROM treenode t1
INNER JOIN treenode t2 ON
( (t1.id = t2.parent_id OR t1.parent_id = t2.id)
OR (t1.parent_id IS NULL AND t1.id = t2.id))
WHERE (t1.LOCATION).z = 41000.0
AND (t1.LOCATION).x > 2822.6
AND (t1.LOCATION).x …
Run Code Online (Sandbox Code Playgroud) 使用 PostgreSQL 10.3。
CREATE TABLE tickets (
id bigserial primary key,
state character varying,
closed timestamp
);
CREATE INDEX "state_index" ON "tickets" ("state")
WHERE ((state)::text = 'open'::text));
Run Code Online (Sandbox Code Playgroud)
该表包含 1027616 行,其中 51533 行具有state = 'open'
和closed IS NULL
或 5%。
条件为 on 的查询state
按预期使用索引扫描执行良好:
explain analyze select * from tickets where state = 'open';
Index Scan using state_index on tickets (cost=0.29..16093.57 rows=36599 width=212) (actual time=0.025..22.875 rows=37346 loops=1)
Planning time: 0.212 ms
Execution time: 25.697 …
Run Code Online (Sandbox Code Playgroud) postgresql performance index postgresql-10 postgresql-performance