标签: postgresql-performance

我在查询中有多个条件，如下所示：

SELECT * FROM image WHERE name LIKE '%text%' AND group_id = 10 LIMIT 1

WHERE 语句由 3 个条件组成：

• 文字匹配
• 外键匹配

如果我想按相关性对结果进行排序，那么取决于：

1. 文本匹配的精确程度
2. 到底满足了多少条件（例如文本匹配和外键）

这是两个问题合而为一的问题，但我认为有时这些问题结合起来会很方便。我指的是我以前的帖子中出现的一个问题（Way to try multiple SELECTs Until a result is available?）。

提前致谢！

我浏览了一些其他帖子并设法使我的查询运行得更快。但是，我对如何进一步优化此查询感到茫然。我将在一个网站上使用它，它会在页面加载时执行查询，但是 5.5 秒对于等待应该更简单的东西来说太长了。最大的表大约有 4,000,000 行，其他的每行大约有 400,000。

表结构

比赛

id BIGINT PRIMARY KEY,
region TEXT,
matchType TEXT,
matchVersion TEXT

团队

matchid BIGINT REFERENCES match(id),
id INTEGER,
PRIMARY KEY(matchid, id),
winner TEXT

冠军

id INTEGER PRIMARY KEY,
version TEXT,
name TEXT

物品

id INTEGER PRIMARY KEY,
name TEXT

参与者

PRIMARY KEY(matchid, id),
id INTEGER NOT NULL,
matchid BIGINT REFERENCES match(id),
championid INTEGER REFERENCES champion(id),
teamid INTEGER,
FOREIGN KEY (matchid, teamid) REFERENCES team(matchid, id),
magicDamageDealtToChampions REAL,
damageDealtToChampions REAL,
item0 TEXT,
item1 TEXT,
item2 …

在我的 PostgreSQL 11.11 中，我有一列jsonb保存如下对象：

{
   "dynamicFields":[
      {
         "name":"200",
         "hidden":false,
         "subfields":[
            {
               "name":"a",
               "value":"Subfield a"
            },
            {
               "name":"b",
               "value":"Subfield b"
            }           
         ]
      }
   ]
}

dynamicFields是一个数组，subfields也是一个数组，当我点击这样的选择时遇到性能问题：

select *
from my_table a
cross join lateral jsonb_array_elements(jsonb_column -> 'dynamicFields') df
cross join lateral jsonb_array_elements(df -> 'subfields') sf
where df ->> 'name' = '200' and sf ->> 'name' = 'a'

性能问题主要存在于subfield. 我已经添加了这样的索引：

CREATE INDEX idx_my_index ON my_table USING gin ((marc->'dynamicFields') jsonb_path_ops);

如何为subfields内部添加索引dynamicFields？
上面的查询只是一个示例，我在与数据库中其他表的联接中经常使用它。而且我也认识 …

我有一个包含大约 700 万条记录的表。该表有一个名字和姓氏列，我想使用 levenshtein() 距离函数进行搜索。

select levenshtein('JOHN', first_name) as fn_distance,
       levenshtein('DOE', last_name) as ln_distance,
       id,
       first_name as "firstName",
       last_name as "lastName"
  from person
 where first_name is not null
   and last_name is not null
   and levenshtein('JOHN', first_name) <= 2
   and levenshtein('DOE', last_name) <= 2
 order by 1, 2
 limit 50;

上面的搜索很慢（4 - 5 秒），我可以做些什么来提高性能？应该在两列上创建索引，还是其他什么？

添加以下索引后：

create index first_name_idx on person using gin (first_name gin_trgm_ops);

create index last_name_idx on person using gin(last_name gin_trgm_ops);

查询现在大约需要 11 秒。:(

新查询：

select similarity('JOHN', first_name) as fnsimilarity, …

我使用 PostgreSQL 14 来管理一个存储医生表更新的表：用户可以更新医生的名字、姓氏和/或年龄。更新操作未触及的字段具有值NULL。

这是涉及两名不同医务人员的四次编辑的示例。ID 为 3 的医生收到了三个更新：前两个正在更新字段age，第三个涉及first_name：

SELECT * FROM medic_edits;

我想合并此表，以便在结果表中每个医生有一行，提供累积编辑。这是我当前的查询及其产生的输出：

SELECT
  medic_id,
  (ARRAY_REMOVE(ARRAY_AGG(first_name ORDER BY id DESC), NULL))[1] AS first_name,
  (ARRAY_REMOVE(ARRAY_AGG(last_name ORDER BY id DESC), NULL))[1] AS last_name,
  (ARRAY_REMOVE(ARRAY_AGG(age ORDER BY id DESC), NULL))[1] AS last_name
FROM medic_edits
GROUP BY medic_id
;

这正是我所期望的输出，但我怀疑这个ARRAY_REMOVE/ARRAY_AGG逻辑有点浪费。我想知道是否有一种方法可以在这里使用分区来获得良好的利润，该 …

我有一个包含超过 30,000,000 个条目的数据库。当对字段执行查询（包括ORDER BY子句）时text，=运算符会产生相对较快的结果。然而我们注意到，当使用该LIKE运算符时，查询变得非常慢，需要几分钟才能完成。例如：

SELECT * FROM work_item_summary WHERE manager LIKE '%manager' ORDER BY created;

对正在搜索的关键字创建索引当然会大大加快查询速度。问题是我们必须支持对任意模式和任意列的查询，使得这个解决方案不可行。

我的问题是：

1. 为什么LIKE查询比查询慢得多=？
2. 有没有其他方法可以优化这些通用查询，或者对于具有如此多条目的数据库来说是最好的？

我有一个名为资产的表。这是 ddl：

create table assets (
    id            bigint                                 primary key,
    name          varchar(255)                           not null,
    value         double precision                       not null,
    business_time timestamp with time zone,
    insert_time   timestamp with time zone default now() not null
);

create index idx_assets_name on assets (name);

我需要为每个资产名称提取最新的（基于 insert_time）值。这是我最初使用的查询：

SELECT DISTINCT
    ON (a.name) *
FROM home.assets a
WHERE a.name IN (
                 'USD_RLS',
                 'EUR_RLS',
                 'SEKKEH_RLS',
                 'NIM_SEKKEH_RLS',
                 'ROB_SEKKEH_RLS',
                 'BAHAR_RLS',
                 'GOLD_18_RLS',
                 'GOLD_OUNCE_USD',
                 'SILVER_OUNCE_USD',
                 'PLATINUM_OUNCE_USD',
                 'GOLD_MESGHAL_RLS',
                 'GOLD_24_RLS',
                 'STOCK_IR',
                 'AED_RLS',
                 'GBP_RLS',
                 'CAD_RLS',
                 'CHF_RLS',
                 'TRY_RLS',
                 'AUD_RLS',
                 'JPY_RLS',
                 'CNY_RLS',
                 'RUB_RLS',
                 'BTC_USD'
    )
ORDER BY …

这个问题有一段时间了，想知道是否有更快的查询。

我有一个表，每个 ID 包含多个条目，并且想要列出同一 ID 具有不同值的所有列。

上表示例：
行ID = 1具有不同的Brand和Type值，因此我希望每一列有一个结果行。
由于ID = 2只有一个品牌，但有多种类型，所以类型只有一个结果行。

想要的结果会是这样的。

我通过下面的查询解决了这个问题，用一个SELECT语句检查每一列，然后UNION全部完成：

SELECT ID, 'Brand' AS Discrepancy
FROM table
GROUP BY ID
HAVING COUNT(DISTINCT Brand) > 1

UNION 

SELECT ID,'Type' AS Discrepancy
FROM table
GROUP BY ID
HAVING COUNT(DISTINCT Type) > 1; …

我正在使用PostgreSQL 9.1.1和Rails 3.2.8.使用NewRelic的开发模式我注意到在我的服务器启动或重启后的第一个请求期间,与后续请求期间相比,几个SQL查询需要更长的时间.

是否有任何理由,这是由于准备好的陈述？

当表较小时，此查询具有合理的时间。我正在尝试确定什么是瓶颈，但是我不确定如何分析EXPLAIN结果。

SELECT
  COUNT(*)
FROM performance_analyses
INNER JOIN total_sales ON total_sales.id = performance_analyses.total_sales_id
WHERE
  (size > 0) AND
  total_sales.customer_id IN (
    SELECT customers.id FROM customers WHERE customers.active = 't'
    AND customers.visible = 't' AND customers.organization_id = 3
  ) AND
  total_sales.product_category_id IN (
    SELECT product_categories.id FROM product_categories
    WHERE product_categories.organization_id = 3
  ) AND
  total_sales.period_id = 193;

我已经尝试了INNER JOIN'ing customers和product_categories表的方法以及执行INNER SELECT的方法。两者有相同的时间。

这是EXPLAIN的链接：https : //explain.depesz.com/s/9lhr

Postgres版本：

x86_64-unknown-linux-gnu上的PostgreSQL 9.4.5，由gcc（GCC）4.8.2 20140120（Red Hat 4.8.2-16）编译，64位

表和索引：

CREATE TABLE total_sales (
  id serial …