标签: postgresql-performance

我必须通过调整基本的PostgreSQL服务器配置参数来优化查询.在文档中,我遇到了work_mem参数.然后我检查了如何更改此参数会影响我的查询的性能(使用sort).我用各种work_mem设置测量了查询执行时间,非常失望.

我执行查询的表包含10,000,000行,并且有430 MB的数据要排序.(Sort Method: external merge Disk: 430112kB).

用work_mem = 1MB,EXPLAIN输出是:

Total runtime: 29950.571 ms (sort takes about 19300 ms).
Sort  (cost=4032588.78..4082588.66 rows=19999954 width=8) 
(actual time=22577.149..26424.951 rows=20000000 loops=1)
                 Sort Key: "*SELECT* 1".n
                 Sort Method:  external merge  Disk: 430104kB

用work_mem = 5MB:

Total runtime: 36282.729 ms (sort: 25400 ms).
Sort  (cost=3485713.78..3535713.66 rows=19999954 width=8) 
      (actual time=25062.383..33246.561 rows=20000000 loops=1)
      Sort Key: "*SELECT* 1".n
      Sort Method:  external merge  Disk: 430104kB

用work_mem …

根据Postgres文档,它们支持3种数据类型的字符数据:

character varying(n), varchar(n)  variable-length with limit
character(n), char(n)             fixed-length, blank padded
text                              variable unlimited length

Run Code Online (Sandbox Code Playgroud)

在我的应用程序中,我遇到了一些令人不愉快的情况,其中插入/更新查询失败,因为要插入的所需文本超出varchar(n)或char(n)限制.

对于这种情况,更改此类列的数据类型就text足够了.

我的问题是:
如果我们概括并更改每个字符存储列的数据类型text,那么性能/内存方面是否有任何缺点？
如果数据类型的列text每次都存储10个或更少的字符,我应该选择text还是varchar(10)？
如果我追求的text是什么？

我有一个简单的查询来连接两个非常慢的表.我发现查询计划在大表email_activities(~10m行)上执行seq扫描,而我认为使用嵌套循环的索引实际上会更快.

我使用子查询重写了查询,试图强制使用索引,然后注意到一些有趣的东西.如果您查看下面的两个查询计划,您将看到当我将子查询的结果集限制为43k时,查询计划确实使用了email_activities上的索引,而将子查询中的限制设置为甚至44k将导致查询计划使用seq扫描email_activities.一个显然比另一个更有效,但Postgres似乎并不关心.

什么可能导致这个？如果其中一个集合大于特定大小,它是否在某处强制使用散列连接？

explain analyze SELECT COUNT(DISTINCT "email_activities"."email_recipient_id") FROM "email_activities" where email_recipient_id in (select "email_recipients"."id" from email_recipients WHERE "email_recipients"."email_campaign_id" = 1607 limit 43000);
                                                                                            QUERY PLAN
--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
 Aggregate  (cost=118261.50..118261.50 rows=1 width=4) (actual time=224.556..224.556 rows=1 loops=1)
   ->  Nested Loop  (cost=3699.03..118147.99 rows=227007 width=4) (actual time=32.586..209.076 rows=40789 loops=1)
         ->  HashAggregate  (cost=3698.94..3827.94 rows=43000 width=4) (actual time=32.572..47.276 rows=43000 loops=1)
               ->  Limit  (cost=0.09..3548.44 rows=43000 width=4) (actual time=0.017..22.547 rows=43000 loops=1)
                     ->  Index Scan using index_email_recipients_on_email_campaign_id on email_recipients  (cost=0.09..5422.47 rows=65710 width=4) (actual time=0.017..19.168 rows=43000 loops=1) …

我正在尝试加快对 PostgreSQL 数据库中存储的一些 json 数据的查询速度。我继承了一个应用程序，该应用程序查询一个名为 的 PostgreSQL 表，该data表带有一个名为 的字段value，其中值是类型为 json 的 blob jsonb。

它大约有 300 行，但从 5 个 json 元素中选择此数据需要 12 秒。json blob 有点大，但我需要的数据都在 json 嵌套的顶层（如果有帮助的话）。

我尝试添加索引，CREATE INDEX idx_tbl_data ON data USING gin (value);但这没有帮助。我应该使用不同的索引吗？长期愿景是重写应用程序以将数据移出 json，但由于应用程序其他部分的复杂性，这至少需要 30-40 个工作日的工作，所以我想看看是否可以可以在短期内加快速度。

不确定它是否有帮助，但构成此结果集的基础数据不会经常更改。经常发生变化的是 json blob 中更下方的数据。

SELECT
  value::json ->> 'name' AS name,
  value::json ->> 'mnemonic' AS mnemonic,
  value::json ->> 'urlName' AS "urlName",
  value::json ->> 'countryCode' AS "countryCode",
  value::json #>>'{team}' AS team
FROM
  data;

我有这个过程,必须使用pl/pgsql进行一系列查询:

--process:
SELECT function1();
SELECT function2();
SELECT function3();
SELECT function4();

为了能够在一次调用中执行所有操作,我创建了一个过程函数:

CREATE OR REPLACE FUNCTION process()
  RETURNS text AS
$BODY$
BEGIN
    PERFORM function1();
    PERFORM function2();
    PERFORM function3();
    PERFORM function4();
    RETURN 'process ended';
END;
$BODY$
  LANGUAGE plpgsql

问题是,当我总结每个函数自身所用的时间时,总计为200秒,而函数所process()用的时间超过一个小时!

也许这是一个内存问题,但我不知道postgresql.conf应该改变哪种配置.

DB在Debian 8中的PostgreSQL 9.4上运行.

有两个表conversations和messages，我想获取对话及其最新消息的内容。

conversations- id(主键)、名称、创建时间

messages- id、内容、created_at、conversation_id

目前我们正在运行此查询来获取所需的数据

SELECT
    conversations.id,
    m.content AS last_message_content,
    m.created_at AS last_message_at
FROM
    conversations
INNER JOIN messages m ON conversations.id = m.conversation_id
                     AND m.id = (
    SELECT
        id
    FROM
        messages _m
    WHERE
        m.conversation_id = _m.conversation_id
    ORDER BY
        created_at DESC
    LIMIT 1)
ORDER BY
    last_message_at DESC
LIMIT 15
OFFSET 0

上面的查询返回有效数据，但其性能随着行数的增加而降低。有没有其他方法可以提高性能来编写此查询？例如附加小提琴。

http://sqlfiddle.com/#!17/2decb/2

还尝试了已删除答案之一中的建议：

SELECT DISTINCT ON (c.id)
       c.id,
       m.content AS last_message_content,
       m.created_at AS last_message_at
  FROM conversations AS c
 INNER JOIN messages AS m …

我们有一个包含 180m 行、大小为 20 GB 的表。\n表 DDL 为：

create table app.table\n(\n    a_id    integer   not null,\n    b_id    integer   not null,\n    c_id    integer   not null,\n    d_id    integer   not null,\n    e_id    integer   not null,\n    f_id    integer   not null,\n    a_date  timestamp not null,\n    date_added          timestamp,\n    last_date_modified  timestamp default now()\n);\n

价值分布：

\n
• a_id 的范围是 0-160,000,000
\n
• b_id 有一个值（该表是分区表的单个分区的副本，并且该 ID 恰好是分区键）
\n
• c_id的范围是0-4
\n
• d_id 有一个值（当前）
\n
• e_id 有一个值（当前）
\n

主键是复合键：

create table app.table\n(\n    a_id    integer   not null,\n    b_id    integer   not …

我有以下表和索引定义:

CREATE TABLE ticket
(
  wid bigint NOT NULL DEFAULT nextval('tickets_id_seq'::regclass),
  eid bigint,
  created timestamp with time zone NOT NULL DEFAULT now(),
  status integer NOT NULL DEFAULT 0,
  argsxml text,
  moduleid character varying(255),
  source_id bigint,
  file_type_id bigint,
  file_name character varying(255),
  status_reason character varying(255),
  ...
)

我在created时间戳上创建了一个索引,如下所示:

CREATE INDEX ticket_1_idx
  ON ticket
  USING btree
  (created );

这是我的疑问

select * from ticket 
where created between '2012-12-19 00:00:00' and  '2012-12-20 00:00:00'

这个工作正常,直到记录数量开始增长(约500万),现在它将永远回归.

解释分析揭示了这一点:

"Index Scan using ticket_1_idx on ticket  (cost=0.00..10202.64 rows=52543 …

我在表中有350万行acs_objects,我需要检索creation_date具有年份格式和不同的列.

我的第一次尝试:180~200 Sec (15 Rows Fetched)

SELECT DISTINCT to_char(creation_date,'YYYY') FROM acs_objects

我的第二次尝试:35~40 Sec (15 Rows Fetched)

SELECT DISTINCT to_char(creation_date,'YYYY')
FROM (SELECT DISTINCT creation_date FROM acs_objects) AS distinct_date

有没有办法让它更快？ - "我需要在ADP网站上使用它"

我想创建一个临时表，以便能够将它连接到几个表，因为将这些表与建议的临时表的内容连接起来需要很多时间（获取临时表的内容很耗时。重复它一遍又一遍地花费越来越多的时间）。当我的需要完成时，我将删除临时表。我想知道这些临时表是否在其他客户端会话中可见（我的要求是让它们仅对当前客户端会话可见）。我正在使用 postgresql。如果您能为我正在考虑的解决方案提出更好的替代方案，那就太好了。