标签: postgresql-performance

我在postgresql中有一个表,其中包含一个不断更新的数组.

在我的应用程序中,我需要获取该数组列中不存在特定参数的行数.我的查询如下所示:

select count(id) 
from table 
where not (ARRAY['parameter value'] <@ table.array_column)

但是当增加行的数量和该查询的执行量(每秒几次,可能是数百或数千)时,性能会下降很多,在我看来,postgresql中的计数可能具有线性执行顺序(I我不完全确定这一点.

基本上我的问题是:

是否有一种我不知道的现有模式适用于这种情况？什么是最好的方法呢？

你能给我的任何建议都会非常感激.

我有这样的模特

具有以下表格大小:

+------------------+-------------+
| Table            |    Records  |
+------------------+-------------+
| JOB              |         8k  |
| DOCUMENT         |       150k  |
| TRANSLATION_UNIT |      14,5m  |
| TRANSLATION      |      18,3m  |
+------------------+-------------+

现在进行以下查询

select translation.id
from "TRANSLATION" translation
   inner join "TRANSLATION_UNIT" unit
     on translation.fk_id_translation_unit = unit.id
   inner join "DOCUMENT" document
     on unit.fk_id_document = document.id     
where document.fk_id_job = 11698
order by translation.id asc
limit 50 offset 0

完成大约需要90秒.当我删除ORDER BY和LIMIT子句时,需要19.5秒.在执行查询之前,已在所有表上运行ANALYZE.

对于此特定查询,这些是满足条件的记录数:

+------------------+-------------+
| Table …

我有一个包含3个字段的postgres表:

• a:postgis几何
• b:array varchar []
• c:整数

我有一个涉及所有这些问题的查询.我想添加一个多列索引来加速它,但我不能因为它们的性质而不能将3个字段放在同一个索引下.

这种情况下的策略是什么？添加3个索引gist,gin和btree以及postgres将在查询期间使用它们吗？

我有以下表格:

CREATE TABLE views (
    view_id bigint NOT NULL,
    usr_id bigint,
    ip inet,
    referer_id bigint,
    country_id integer,
    validated smallint,
    completed smallint,
    value numeric
);

ALTER TABLE ONLY views
    ADD CONSTRAINT "Views_pkey" PRIMARY KEY (view_id);

CREATE TABLE country (
    country_id integer NOT NULL,
    country character varying(2)
);

ALTER TABLE ONLY country
    ADD CONSTRAINT country_pkey PRIMARY KEY (country_id);

CREATE TABLE file_id_view_id (
    file_id bigint,
    view_id bigint,
    created_ts timestamp without time zone
);

CREATE TABLE file_owner (
    file_id bigint NOT NULL,
    owner_id bigint …

我有一个名为PostgreSQL的表queries_query,它有很多列.

其中两个列created和user_sid我的应用程序经常在SQL查询中一起使用,以确定给定用户在过去30天内完成了多少查询.在最近30天之前的任何时间查询这些统计数据是非常非常罕见的.

这是我的问题:

我目前通过运行以下方法在这两列上创建了我的多列索引:

CREATE INDEX CONCURRENTLY some_index_name ON queries_query (user_sid, created)

但我想进一步限制索引只关心创建日期在过去30天内的查询.我尝试过以下方法:

CREATE INDEX CONCURRENTLY some_index_name ON queries_query (user_sid, created)
WHERE created >= NOW() - '30 days'::INTERVAL`

但这引发了一个异常,说明我的函数必须是不可变的.

我很乐意让这个工作,以便我可以优化我的索引,并削减Postgres需要执行这些重复查询的资源.

我有一个vote_pairs看起来像这样的视图:

CREATE VIEW vote_pairs AS
    SELECT
        v1.name as name1,
        v2.name as name2,
        ...
    FROM votes AS v1
    JOIN votes AS v2
        ON v1.topic_id = v2.topic_id;

并且,如果votes表中有大约100k行,则跨此视图的查询大约需要3秒钟才能执行.

但是,当我在名称上添加额外的过滤器时:

… ON v1.topic_id = v2.topic_id AND v1.name < v2.name;

运行时间翻了四倍,查询vote_pairs完成时间大约需要12秒.

无论限制的位置如何,此运行时都是一致的...例如,如果将过滤器移动到WHERE外部查询的子句,则查询同样很慢:

SELECT * FROM vote_pairs WHERE name1 < name2;

这是怎么回事？Postgres的词典比较速度慢吗？这是别的吗？我怎么能提高这个查询的速度？

投票表:

CREATE TABLE votes (
    topic_id INTEGER REFERENCES topics(id),
    name VARCHAR(64),
    vote VARCHAR(12)
)

CREATE INDEX votes_topic_name ON votes (topic_id, name);
CREATE INDEX votes_name ON …

您好任何想法如何加快这个查询？

输入

EXPLAIN SELECT entityid FROM entity e

LEFT JOIN level1entity l1 ON l1.level1id = e.level1_level1id
LEFT JOIN level2entity l2 ON l2.level2id = l1.level2_level2id
WHERE 

l2.userid = 'a987c246-65e5-48f6-9d2d-a7bcb6284c8f' 
AND 
(entityid NOT IN 
(1377776,1377792,1377793,1377794,1377795,1377796... 50000 ids)
)

产量

Nested Loop  (cost=0.00..1452373.79 rows=3865 width=8)
  ->  Nested Loop  (cost=0.00..8.58 rows=1 width=8)
        Join Filter: (l1.level2_level2id = l2.level2id)
        ->  Seq Scan on level2entity l2  (cost=0.00..3.17 rows=1 width=8)
              Filter: ((userid)::text = 'a987c246-65e5-48f6-9d2d-a7bcb6284c8f'::text)
        ->  Seq Scan on level1entity l1  (cost=0.00..4.07 rows=107 width=16)
  ->  Index Scan using fk_fk18edb1cfb2a41235_idx …

我正在尝试获取表中最近的行.我有一个简单的时间戳created_at索引.当我查询时ORDER BY created_at DESC LIMIT 1,它需要的远远超过我的想象(我的机器上36k行约50ms).

EXPLAIN -ing声称它使用向后索引扫描,但我确认更改索引(created_at DESC)不会改变查询规划器中的简单索引扫描的成本.

如何优化此用例？

运行postgresql 9.2.4.

编辑:

# EXPLAIN SELECT * FROM articles ORDER BY created_at DESC LIMIT 1;
                                                  QUERY PLAN                                                       
-----------------------------------------------------------------------------------------------------------------------
Limit  (cost=0.00..0.58 rows=1 width=1752)
   ->  Index Scan Backward using index_articles_on_created_at on articles  (cost=0.00..20667.37 rows=35696 width=1752)
(2 rows)

对于~700个ID的列表,查询性能比传递返回700个ID的子查询慢20多倍.应该是相反的.

例如(第一次查询不到400毫秒,后来的9600毫秒)

select date_trunc('month', day) as month, sum(total)
from table_x
where y_id in (select id from table_y where prop = 'xyz') 
and day between '2015-11-05' and '2016-11-04' 
group by month

我的机器比直接传递数组快20倍:

select date_trunc('month', day) as month, sum(total) 
from table_x
where y_id in (1625, 1871, ..., 1640, 1643, 13291, 1458, 13304, 1407, 1765) 
and day between '2015-11-05' and '2016-11-04' 
group by month 

知道可能是什么问题或如何优化和获得相同的性能？

我可以采取任何其他步骤来加快查询执行速度吗？

我有一个超过 100m 行的表，我需要搜索匹配的字符串。为此，我检查了两个选项：

\n
1. 将文本与 to_tsvector @@（to_tsquery 或 plainto_tsquery）进行比较
   \n这工作得非常快（所有数据都在 1 秒以下），但在查找文本相似性方面存在一些问题
\n
2. 将文本与 pg_trgm 相似度进行比较\n这对于文本比较效果很好，但对于大量数据则效果不佳。
\n

我发现我可以使用索引来提高性能。\n对于我的 GiST 索引，我尝试siglen从小数字增加到 2024，但由于某种原因 Postgres 使用512而不是更高。

CREATE INDEX trgm_idx_512_gg ON table USING GIST (name gist_trgm_ops(siglen=512));\n

询问：

SELECT name, similarity(name, '\xd0\xbd\xd0\xbe\xd1\x83\xd1\x82\xd0\xb1\xd1\x83\xd0\xba MSI GF63 Thin 10SC 086XKR 9S7 16R512 086') as sm\nFROM table\nWHERE name % '\xd0\xbd\xd0\xbe\xd1\x83\xd1\x82\xd0\xb1\xd1\x83\xd0\xba MSI GF63 Thin 10SC 086XKR 9S7 16R512 086' \n

EXPLAIN输出：

Bitmap Heap Scan on …