标签: postgresql

我正在编写一个 Drupal 模块，我希望它在 PostgreSQL 和 MySQL 之间是不可知的。我有一个从条件中获取其值的字段，我最初将它写为IF(). 然后我发现这IF()是一个 MySQL 主义。所以，我查找了 PostgreSQL 的条件语句，CASE似乎是最好的工具。

但是，我注意到以 PostgreSQLCASE结尾END，而在MySQL 中以END CASE. 这会破坏我对数据库不可知论的希望吗？我可以用条件编写一个不可知的查询吗？

我读到MySQL 有二进制安全 blob，但 PostgreSQL 没有。

到目前为止，我所发现的表明“二进制安全”是真正与功能和数据处理相关的东西，而不是数据本身。似乎不同之处在于 MySQL 本身具有存储和操作 blob 的方法，而无需指定数据格式，但 PostgreSQL 需要对二进制数据使用“带引号的可打印编码”或“base64” 编码。

这就是全部吗？关于 MySQL 和 PostgreSQL 在处理 blob 方面的差异，我还应该担心什么？我正在开始一个新项目，而不是迁移数据，所以我只是想知道在处理二进制 blob 方面是否有特殊的理由来选择一个或另一个。

我在我的所有职业生涯中都使用过 MySQL 和 SQL 服务器。

我将工作的公司使用 PostgreSQL。

曾经/处于类似情况的人能否让我了解最大的区别是什么以及我将使用哪些类型的客户端工具来连接和管理数据库？

谢谢

到目前为止，我的 PostgreSQL 应用程序中的所有查询都很快。在过去的几天里，有时一个查询需要几个小时。索引是健康的，因为在 dump、restore、vacuum -z 之后，它仍然是一样的：查询需要几个小时。

EXPLAIN  VERBOSE SELECT DISTINCT "modwork_beleg"."direction" 
FROM "modwork_beleg" 
LEFT OUTER JOIN "modwork_isu_isu_pkunde" ON ("modwork_beleg"."id" = "modwork_isu_isu_pkunde"."beleg_id")
LEFT OUTER JOIN "modwork_isu_isu_vknr"   ON ("modwork_beleg"."id" = "modwork_isu_isu_vknr"."beleg_id")
LEFT OUTER JOIN "modwork_isu_isu_gpnr"   ON ("modwork_beleg"."id" = "modwork_isu_isu_gpnr"."beleg_id")
WHERE ("modwork_beleg"."state" IN (E'neu', E'inarbeit', E'wiedervorlage')
    AND (
      "modwork_isu_isu_pkunde"."pkunde" = 90237758
      OR
      "modwork_isu_isu_vknr"."vknr" = 254400297729
      OR
      "modwork_isu_isu_gpnr"."gpnr" = 1001030921
));

查询计划：

 HashAggregate  (cost=36409.29..36409.30 rows=1 width=3)
   Output: modwork_beleg.direction
   ->  Merge Right Join  (cost=28836.70..36409.29 rows=1 width=3)
         Output: modwork_beleg.direction
         Merge Cond: (modwork_isu_isu_vknr.beleg_id = modwork_beleg.id)
         Filter: ((modwork_isu_isu_pkunde.pkunde …

我在我的项目中使用 PostgreSQL，现在我错误地删除了我的一个表的一些记录。现在有什么方法可以恢复 PostgreSQL 中已删除的记录吗？

我们维护着所有空闲或分配给主机的 SAN 交换机端口的列表。目前，我们在公司门户上输入信息。但是我们需要转移到数据库，因为到目前为止我们有大约 2200 行数据，每行有 10 列。将数据提取到excel表中后我得到了数字。我预计在几个月内至少会添加 1000 多行。

我们所有的 SAN Mgmt 服务器都是 windows 2003，但都没有安装 MS Office，因此不能使用 MS Excel。因此需要一个开源数据库。

我试过 MySQL 和 PostgreSQL。我发现 MySQL 更容易处理，但我读过数据可靠性明智的 PostgreSQL 更好。我尝试了这两个数据库几天，将 CSV 文件导入到这两个数据库中，因为与手动输入 2200 个条目相比，这更容易。MySQL 和 PostgreSQL 似乎都做得很好。但是，我不得不编辑 CSV 文件，因为在单元格的某些地方使用了字段分隔符“,”，这使其中断并扭曲了 MySQL 中的条目。PostgreSQL 在这方面没有任何问题。

对经验丰富的数据库管理员的请求 - 请让我知道 MySQL 是否足以满足我的需求？MySQL 是否有数据损坏的可能性？或者现在就迁移到 PostgreSQL 会更好吗？

我很抱歉在这里没有使用特定于数据库的术语，因为我不是来自数据库背景。

请告诉我。

我写了一个脚本来备份 postgresql COPY，然后删除这些记录。pg_relation_size删除前后我都用过。

1. pg_relation_size
2. 删除
3. 真空分析
4. pg_relation_size

但两者都pg_relation_size显示相同的结果。这是否意味着VACUUM ANALYZE没有帮助？

最初发布：https : //stackoverflow.com/questions/11173717/expensive-query-on-select-distinct-with-multiple-inner-join-in-postgres

歌曲表只有大约 4k 行，帖子和电台更少。运行查询而不DISTINCT ON修复它。

在 Mac OS X Lion 上运行 Postgres。

Song Load (7358.2ms)

EXPLAIN (426.2ms)

EXPLAIN for: 
SELECT  DISTINCT ON (songs.rank, songs.shared_id) songs.*, 
        songs.*, 
        posts.url as post_url, 
        posts.excerpt as post_excerpt, 
        stations.title as station_title, 
        stations.slug as station_slug 
FROM "songs" 
    INNER JOIN "posts" ON "posts"."id" = "songs"."post_id" 
    inner join stations on stations.blog_id = songs.blog_id 
WHERE "songs"."processed" = 't' 
  AND "songs"."working" = 't' 
ORDER BY songs.rank desc 
LIMIT 24 OFFSET 0

                                           QUERY PLAN
------------------------------------------------------------------------------------------------
 Limit  (cost=546147.28..546159.16 …

我正在尝试优化在 PostgreSQL 15.4 中连接两个大表（40MM+ 行）的查询。

SELECT files.id, ARRAY_AGG(b.status)\nFROM files\nLEFT OUTER JOIN processing_tasks b\n    ON (files.id = b.file_id AND b.job_id = 113)\nWHERE files.round_id = 591\nGROUP BY files.id;\n

explain (analyze)完全相同的查询的两个计划位于：

\n

• https://explain.depesz.com/s/cUXB需要 87 秒，使用并行 Seq 扫描processing_tasks.job_id（默认计划）

  \n
\n

• https://explain.depesz.com/s/j39G需要 4 秒，使用位图索引扫描processing_tasks.job_id（当 时set local enable_seqscan = OFF）

  \n
\n

在 中files，908,275 / 39,000,105 (2.3%) 个元组有round_id=591; 它是静态的。
\n在 中processing_tasks，4,026,364 / 60,780,802 (6.6%) 个元组有job_id=113，并且随着行的插入，这个值将变得越来越常见，可能达到表的 …

我试过这个：

create or replace function c3 (arg char(3))
  returns void
  language plpgsql as
$$
begin
  raise notice 'Value: %', arg;
end;
$$;

但它接受三个以上的字符：

select c3('1234');