标签: postgresql-performance

我在另一个论坛上遇到了这个：

PG 对于IN查询中的值的限制为 100，之后不使用所述列上的索引。例如：SELECT ... WHERE IN (...)如果 IN 列表超过 100，则对 PK的典型查询将变成全表扫描。

我无法找到任何关于此的信息。PG 有没有这样的限制（我是这么想的），如果有，这个限制是多少？

我知道有时在临时表中使用大型子选择会更好，但是了解截止位置会很有帮助。

是否有任何可用于 Postgresql 的类似于 SQL Server 查询存储的扩展。这样它可以帮助识别性能瓶颈。

SQL Server 查询存储提供有关查询执行次数、每个查询的资源消耗的信息。https://learn.microsoft.com/en-us/sql/relational-databases/performance/monitoring-performance-by-using-the-query-store?view=sql-server-ver15提供了有关查询存储的更多详细信息。

我将 Postgres 13.3 与内部和外部查询一起使用，它们都只产生一行（只是一些关于行数的统计数据）。

我不明白为什么下面的 Query2 比 Query1 慢得多。它们基本上应该几乎完全相同，最多可能只有几毫秒的差异......

查询 1：需要 49 秒

WITH t1 AS (
        SELECT
            (SELECT COUNT(*) FROM racing.all_computable_xformula_bday_combos) AS all_count,
            (SELECT COUNT(*) FROM racing.xday_todo_all) AS todo_count,
            (SELECT COUNT(*) FROM racing.xday) AS xday_row_count
        OFFSET 0 -- this is to prevent inlining
)

SELECT
            t1.all_count,
            t1.all_count-t1.todo_count AS done_count,
            t1.todo_count,
            t1.xday_row_count
FROM t1;

查询 2：需要 4 分 30 秒

我只添加了一行：

WITH t1 AS (
        SELECT
            (SELECT COUNT(*) FROM racing.all_computable_xformula_bday_combos) AS all_count,
            (SELECT COUNT(*) FROM racing.xday_todo_all) AS todo_count,
            (SELECT COUNT(*) …

我有一个包含超过 10.000.000 条记录的表，并且我正在创建一个返回大约 4436 条记录的查询。

碰巧它给我的印象是获取最后一条记录的查询成本非常高。

Index Scan using idx_name on task  (cost=0.28..142102.57 rows=3470 width=34) (actual time=14.690..22.894 rows=4436 loops=1)
"  Index Cond: ((situation = ANY ('{0,1,2,3,6,7,8,9,10,11,12,13,14,15,16,17,18,19,20}'::integer[])) AND (deadline < CURRENT_TIMESTAMP))"
Planning Time: 1.335 ms
JIT:
  Functions: 5
  Options: Inlining false, Optimization false, Expressions true, Deforming true
  Timing: Generation 1.654 ms, Inlining 0.000 ms, Optimization 1.214 ms, Emission 13.163 ms, Total 16.030 ms
Execution Time: 24.758 ms

这个成本水平是否可以接受，或者这个指标是否需要改进？

指数：

CREATE INDEX idx_name ON task (situation, deadline, approved)
WHERE
deadline IS NOT …

我有10-15个大表，5GB到30GB。其余的都小于1GB。有些表数据很大，每天会产生 500 000 个死元组。大约 7 天后，当死亡元组超过 350 万个时，自动清理就会开始。该数据库大约有 60 个表。这里数据库的阈值是：20%。

我想将 autovacuum 阈值从 20% 更改为 1%。对系统性能有什么影响（因为对于较小的表，它会频繁运行）。maintanance_work_mem 和 work_mem 参数值应该是什么？

T 开头的文件名太多

(T14_xxxxxxxx.1, T14_xxxxxxxx.2 .. T14_xxxxxxxx.18)

在一个数据库的 postgresql 基本目录中。

基本目录中的数据库大小为 500GB，包含这些文件。重新启动postgresql后，这些文件消失了，base/目录中的数据库大小减少了200GB。

我阅读了以下网站。但我找不到有关这些文件的任何信息：

https://www.postgresql.org/docs/current/storage-file-layout.html#:~:text=For%20each%20database%20in%20the,system%20catalogs%20are%20stored%20there.>

另外我还使用了 pg_relation_filepath 或选择 pg_class 表。我没有找到有关这些文件的任何信息。

“base”目录中的这些大文件是什么？这些是缓存文件吗？应用程序怎么会出现这些文件呢？

我正在尝试查询 125GB Postgres 数据库中的几个表。我发现很难快速返回结果！

即使找到一列的唯一行也需要 10 多分钟。我使用命令行或 PHPMyAdmin 之类的工具来触发查询，等待时间保持不变。

例如：

SELECT COUNT (DISTINCT column_name) FROM table_name;

我担心如果在这些表上使用连接操作，这个等待时间会显着增加并且会更加痛苦。

任何人都可以提出什么可能是快速恢复统计数据的可能解决方案？

我正在尝试计算两个坐标之间的距离并根据一些条件获取一些信息。一个类似的带有 'have' 子句的查询在 MySQL 中工作。但是为什么它在 PostgreSQL 中不起作用呢？

这是我的查询：

    SELECT *, ( 6371 * acos( cos( radians(latitude) ) * cos( radians( latitude1 ) ) *
    cos( radians( longitude1 ) - radians(longitude) ) + sin( radians(latitude) ) *
    sin( radians( latitude1 ) ) ) ) AS distance from table WHERE
    verified=true AND best_for LIKE '%xyz%' AND uuid NOT IN (SELECT uuid::uuid FROM table2 WHERE
    from_date BETWEEN '2020-12-17 06:30'::date AND '2020-12-18 12:30'::date AND
    to_date BETWEEN '2020-12-17 06:30'::date AND '2020-12-18 12:30'::date  AND )
    HAVING …

我看过很多文章和视频，它们都对 MySQL 上的 Postgres 进行了如下描述。

Postgres 在为每个连接分叉一个新进程时会分配大量内存（大约 10MB）。这会导致内存使用量膨胀并有效地消耗速度。因此，它牺牲了数据完整性和标准合规性的速度。对于简单的实现，Postgres 将是一个糟糕的选择！- 相扑逻辑

每次我在某处读到或听到它时，都没有关于它真正意味着什么或是否有办法处理它的上下文。在 PostgreSQL 中处理这类问题的具体方法是什么？这是通过使用连接池来克服的吗？

你能解释一下，我如何优化这样的选择：

SELECT * FROM calls WHERE id_temp % 5 = 0 LIMIT 300000

此选择正在处理具有 5000 万条记录的表。

非常感谢，祝你有美好的一天。