我正在 Postgres 11.5 中编写一组存储函数，并且希望RAISE EXCEPTION在不满足各种先决条件时执行此操作。例如null需要一个字符串或者带字符串的空字符串，或者超出范围的整数参数等。
我可以RAISE EXCEPTION提供详细信息、提示和消息...但是错误代码应该使用什么范围？我检查了文档，但没有在这里找到任何指导：
https://www.postgresql.org/docs/11/errcodes-appendix.html
我在 StackOverflow 上搜索，发现几年前有一个类似的问题......但没有明确的答案。
是否有一些块或前缀可以安全或常规地用于从存储的函数/过程返回的自定义错误代码？
RDS 上的 Postgres 11.4 和家里的 11.5。
我今天更仔细地查看哈希索引，因为我遇到了 citext 索引被忽略的问题。而且我发现我不明白为什么哈希索引如此之大。当我预计它需要 10 个字节 + 一些开销时，它需要大约 50 个字节/行。
我有一个示例数据库，其中包含一个名为 record_changes_log_detail 的表，该表有 7,733,552 条记录，因此约为 8M。在该表中有一个名为 old_value 的 citext 字段，它是哈希索引的来源：
CREATE INDEX record_changes_log_detail_old_value_ix_hash
ON record_changes_log_detail
USING hash (old_value);
这是对索引大小的检查：
select
'record_changes_log_detail_old_value_ix_hash' as index_name,
pg_relation_size ('record_changes_log_detail_old_value_ix_hash') as bytes,
pg_size_pretty(pg_relation_size ('record_changes_log_detail_old_value_ix_hash')) as pretty
这将返回 379,322,368 字节，或大约 362MB。我已经深入挖掘了源代码，并且对这篇精美的作品进行了更多研究。
听起来像行的哈希索引条目是与哈希键本身配对的 TID。以及页面内的某种索引计数器。那是两个 4 字节的整数，我猜是 1 或 2 字节的整数。作为一个简单的计算，10 字节 * 7,733,552 = 77,335,520。实际索引大约比那个大 5 倍。诚然，您需要为索引结构本身提供空间，但它不应该将每行的粗略成本从 ~10 字节到 ~50 字节，对吗？
这是索引的详细信息，使用pageinspect扩展阅读，然后手动旋转以提高可读性。
select * …我一直在尝试使用 tsvector 索引进行全文搜索，并且看到在 tsvector 类型的列中生成一个存储向量是一种常见的做法。我们使用的是 Postgres 11.4，但我已经看到这种做法用作 PG 12 生成列的示例。（比出于相同目的使用触发器更简单。）
我的问题是，有什么好处？我在文本字段的 tsvector 上尝试了表达式 GIN 索引，并在存储的 tsvector 上尝试了 GIN 索引。本地大约有 800 万行，我无法测量任何有意义的速度差异。鉴于将向量存储为列和索引需要更多空间，我很好奇是否有明显的情况证明额外成本是合理的。例如，当您有更多角色时。
注意：我们将文本存储在数据库中，因此这不是您在不将源文本吸收到数据库中的情况下索引外部页面/文档/等的设置之一。
Postgres 中的完整计数可能会很慢，其原因众所周知且经过多次讨论。因此，在可能的情况下，我一直在使用估计技术。对于行， pg_stats 似乎很好，对于视图，提取由 工作返回的估计也EXPLAIN可以。
https://www.cybertec-postgresql.com/en/count-made-fast/
但不同的价值观又如何呢？在这里，我的运气要差很多。有时估计是 100% 正确的，有时会偏离 2 或 20 倍。截断的表似乎特别有严重过时的估计（？）。
我刚刚运行了这个测试并提供了一些结果：
analyze assembly_prods; -- Doing an ANLYZE to give pg_stats every help.
select 'count(*) distinct' as method,
count(*) as count
from (select distinct assembly_id
from assembly_prods) d
union all
select 'n_distinct from pg_stats' as method,
n_distinct as count
from pg_stats
where tablename = 'assembly_prods' and
attname = 'assembly_id';
结果：
method count
count(*) distinct 28088
n_distinct from pg_stats 13805
虽然只相差了 2 倍，但我的数据似乎更糟糕。到了我不会使用估计的地步。我还有什么可以尝试的吗？这是PG 12改进的吗？
我有一个包含文本列的表格，我想按word搜索，而不是lexeme。更重要的是，我想按单词而不是词素进行索引。我们有大量代码引用的错误转储，它们不适用于任何自然语言词典。
Postgres 有没有办法让 FTS 按单词边界解析而不将单词解析为词素？如果我必须定义一个边界字符列表和一个跳过词目录，那可能没问题。这是否需要制作某种自定义词典，还是已经有类似的东西可用？
我一直认为我错过了一些明显的东西，然后找不到它。
目前，trigram 索引还可以，但我真的更喜欢文本的唯一关键字解析器。
RDS 上的 Postgres 11.4。