相关疑难解决方法(0)

我有一个 PostgreSQL 表。select *很慢，但又select id好又快。我认为可能是行的大小非常大并且需要一段时间来运输，或者可能是其他一些因素。

我需要所有字段（或几乎所有字段），因此仅选择一个子集不是一个快速解决方案。选择我想要的字段仍然很慢。

这是我的表架构减去名称：

integer                  | not null default nextval('core_page_id_seq'::regclass)
character varying(255)   | not null
character varying(64)    | not null
text                     | default '{}'::text
character varying(255)   | 
integer                  | not null default 0
text                     | default '{}'::text
text                     | 
timestamp with time zone | 
integer                  | 
timestamp with time zone | 
integer                  | 

文本字段的大小可以是任意大小。但是，在最坏的情况下，不会超过几千字节。

问题

1. 有什么关于这叫“疯狂低效”的吗？
2. 有没有办法在 Postgres 命令行中测量页面大小来帮助我调试？

我有一个旧模式（免责声明！），它使用基于哈希生成的 id 作为所有表的主键（有很多）。这种 id 的一个例子是：

922475bb-ad93-43ee-9487-d2671b886479

改变这种方法是不可能的，但是索引访问的性能很差。撇开这可能的无数原因不谈，我注意到有一件事似乎不太理想 - 尽管所有许多表中的所有 id 值的长度都正好是 36 个字符，但列类型是varchar(36)，而不是 char(36)。

将列类型更改为固定长度是否会char(36)提供任何显着的索引性能优势，除了每个索引页的条目数量增加很小等之外？

即在处理固定长度类型时 postgres 的执行速度是否比处理可变长度类型快得多？

请不要提及微小的存储节省 - 与对列进行更改所需的手术相比，这无关紧要。

在这个答案（/sf/ask/36230561/）中，一个评论引起了我的注意：

还要记住，在进行索引比较时，CHAR 和 VARCHAR 之间通常存在很大差异

这是否适用/仍然适用于 Postgres？

我发现 Oracle 上的页面声称这CHAR或多或少是 for 的别名VARCHAR，因此索引性能是相同的，但我在 Postgres 上没有发现任何明确的内容。

我有一个以这种方式创建的表：

--
-- Table: #__content
--
CREATE TABLE "jos_content" (
  "id" serial NOT NULL,
  "asset_id" bigint DEFAULT 0 NOT NULL,
   ...
  "xreference" varchar(50) DEFAULT '' NOT NULL,
  PRIMARY KEY ("id")
);

稍后插入一些行并指定 id：

INSERT INTO "jos_content" VALUES (1,36,'About',...)

稍后，一些记录被插入而没有 id 并且它们因错误而失败： Error: duplicate key value violates unique constraint。

显然，id 被定义为一个序列：

每个失败的插入都会增加序列中的指针，直到它增加到一个不再存在的值并且查询成功。

SELECT nextval('jos_content_id_seq'::regclass)

表定义有什么问题？解决这个问题的聪明方法是什么？

假设我有这张表：

Table "public.orders"
         Column      |     Type      | Collation | Nullable | Default 
    -----------------+---------------+-----------+----------+---------
     o_orderkey      | integer       |           | not null | 
     o_custkey       | integer       |           |          | 
     o_orderstatus   | character(1)  |           |          | 
     o_totalprice    | numeric(12,2) |           |          | 
     o_orderdate     | date          |           |          | 
     o_orderpriority | character(15) |           |          | 
     o_clerk         | character(15) |           |          | 
     o_shippriority  | integer       |           |          | 
     o_comment       | character(79) |           |          |

如果我有涉及o_orderstatus、o_orderpriority或列的查询，我可以将数据类型更改为 以改进它们吗o_clerk？o_commentchar(n)text

目前，我有一个定义如下的视图：

                       View "public.customer_list"
  Column   |          Type           | Modifiers | Storage  | Description 
-----------+-------------------------+-----------+----------+-------------
 id        | bigint                  |           | plain    | 
 name      | character varying(100)  |           | extended | 
 street    | character varying(100)  |           | extended | 
 zip       | character varying(10)   |           | extended | 
 city      | character varying(100)  |           | extended | 
 country   | character varying(3)    |           | extended | 
 phone     | character varying(100)  |           | extended | 
 mail      | character varying(100)  |           | extended | 
 rating    | integer                 | …

我在 Amazon RDS（2vCPU，8 GB RAM）上使用 Postgres 9.5。
我使用 pganalyze 来监控我的表现。
我在数据库中有大约 20 万条记录。

在我的仪表板中，我看到以下查询的平均执行时间为 28 秒和 11 秒：

UPDATE calls SET ... WHERE calls.uuid = ?   telephonist 28035.41    0.01    100%    0.03%

UPDATE calls SET sip_error = ? WHERE calls.uuid = ? telephonist 11629.89    0.44    100%    0.69%

我已经尝试VACUUM、发现并清理了 7,670 个死行。
任何想法如何提高UPDATE性能？这是查询：

UPDATE calls SET X=Y WHERE calls.uuid = 'Z'

如何改进上述查询？我可以添加另一个字段吗？例子：

UPDATE calls SET X=Y WHERE calls.uuid = 'Z' AND calls.campaign = 'W'

该列uuid未编入索引。
https://www.tutorialspoint.com/postgresql/postgresql_indexes.htm建议不建议将索引用于 …

在 Twitter 交流中，西蒙·韦斯特 (Simon West)向布兰杜尔 (Brandur)询问，

\n

出于兴趣，为什么使用email TEXT CHECK (char_length(email) <= 255)而不是email VARCHAR(255)？我以前没有见过这种模式

\n

布兰杜尔回应说，

\n

很好的问题！

\n\n

(1) VARCHAR 和 TEXT 在 Postgres 中的性能相同（请参阅https://www.postgresql.org/docs/current/static/datatype-character.html \xe2\x80\xa6中的“提示”框）。\n 。

\n\n

(2) 如果您想更改长度，ALTER TABLE则需要独占锁（请参阅https://www.postgresql.org/docs/current/static/sql-altertable.html \xe2\x80\xa6）。改变CHECK是即时的。\n 当回答一个引起质疑的问题时text CHECK (char_length(email) <= 255)vsvarchar(255)

\n

这两个断言中的第一个断言（粗体）是否严格正确？

如果对第二个主张感兴趣，请查看此问题。

这个问题与我之前问过的问题有关：PostgreSQL 中复合索引中的列顺序（和查询顺序）

我想我可以在这里尖锐和限制我的问题，而不是超载这个问题。鉴于以下查询（和 EXPLAIN ANALYZE），我正在创建的复合索引有帮助吗？

第一个查询仅使用简单索引（大纲上的 GIST）和（pid 上的 BTREE）运行。

查询是：

EXPLAIN ANALYZE SELECT DISTINCT ON (path) oid, pid, product_name, type, path, size 
FROM portal.inventory AS inv 
WHERE ST_Intersects(st_geogfromtext('SRID=4326;POLYGON((21.51947021484375 51.55059814453125, 18.9129638671875 51.55059814453125, 18.9129638671875 48.8287353515625, 21.51947021484375 48.8287353515625, 21.51947021484375 51.55059814453125))'), inv.outline) 
AND (inv.pid in (20010,20046)) 

——

结果如下（速度更快，但也许这只是因为数据库是热的）。

"Unique  (cost=581.76..581.76 rows=1 width=89) (actual time=110.436..110.655 rows=249 loops=1)"
"  ->  Sort  (cost=581.76..581.76 rows=1 width=89) (actual time=110.434..110.477 rows=1377 loops=1)"
"        Sort Key: path"
"        Sort Method: quicksort  Memory: 242kB"
"        ->  Bitmap Heap Scan on inventory …

我尝试为我的数据创建报告，但在大表上真的很慢。

表结构为：

CREATE TABLE posts
(
  id serial NOT NULL,
  project_id integer,
  moderation character varying(255),
  keyword_id integer,
  author_id integer,
  created_at timestamp without time zone,
  updated_at timestamp without time zone,
  server_id character varying(255),
  social_creation_time integer,
  social_id character varying(255),
  network character varying(255),
  mood character varying(255) DEFAULT NULL::character varying,
  url text,
  source_id integer,
  location character varying(255),
  subject_id integer,
  conversation_id integer,
  CONSTRAINT posts_pkey PRIMARY KEY (id)
);

CREATE INDEX index_posts_on_author_id ON posts (author_id);
CREATE INDEX index_posts_on_keyword_id ON posts (keyword_id);
CREATE INDEX index_posts_on_project_id_and_network_and_social_id 
    ON posts …

介绍

我有一个 PostgreSQL 表设置作为队列/事件源。

我非常希望保留事件的“顺序”（即使在处理队列项之后）作为 e2e 测试的来源。

我开始遇到查询性能下降的问题（可能是因为表膨胀），并且我不知道如何有效地查询不断变化的键上的表。

初始设置

Postgres：v15

表DDL

CREATE TABLE eventsource.events (
    id serial4 NOT NULL,
    message jsonb NOT NULL,
    status varchar(50) NOT NULL,
    createdOn timestamp NOT NULL DEFAULT CURRENT_TIMESTAMP,
    CONSTRAINT events_pkey PRIMARY KEY (id)
);
CREATE INDEX ON eventsource.events (createdOn)

抓取查询（伪代码）

BEGIN;  -- Start transaction

SELECT message, status
FROM eventsource.events ee
WHERE status = 'PENDING'
ORDER BY ee.createdOn ASC
FOR UPDATE SKIP LOCKED
LIMIT 10;  -- Get the OLDEST 10 events that are pending
-- I …

varchar(5)当我在查询中使用时INSERT，这意味着表中的属性将在内存中占用5 个字节？（假设一个可打印字符占用一个字节）？