相关疑难解决方法(0)

我必须编写一个简单的查询，在其中查找以 B 或 D 开头的人名：

SELECT s.name 
FROM spelers s 
WHERE s.name LIKE 'B%' OR s.name LIKE 'D%'
ORDER BY 1

我想知道是否有办法重写它以提高性能。所以我可以避免or和/或like？

谁能解释一下 LIKE 运算符是如何在当前数据库系统（例如 MySQL 或 Postgres）中实现的？或者指出一些解释它的参考资料？

天真的方法是检查每条记录，在感兴趣的字段上执行正则表达式或部分字符串匹配，但我有一种感觉（希望）这些系统做一些更聪明的事情。

我正在尝试json_extract_path_text()使用citext模块制作不区分大小写的版本。

我希望这是一个围绕内置函数的简单包装器，唯一的区别是它接受citext作为第一个参数而不是json. 我希望这是对本机实现的直接传递，只需事先进行类型转换。这是我到目前为止所拥有的：

create extension citext;

create or replace function json_extract_path_text ( string citext, variadic params text[]) RETURNS text IMMUTABLE AS
$$
    BEGIN
        SELECT json_extract_path_text(string::json, params);
    END;
$$
LANGUAGE 'plpgsql';

但是，由于类型不匹配，这不能正常工作：

ERROR:  function json_extract_path_text(json, text[]) does not exist
LINE 1: SELECT json_extract_path_text(string::json, params)
               ^
HINT:  No function matches the given name and argument types. You might need to add explicit type casts.
QUERY:  SELECT json_extract_path_text(string::json, params)
CONTEXT:  PL/pgSQL function json_extract_path_text(citext,text[]) line 3 …

Run Code Online (Sandbox Code Playgroud)

我想要 PostgreSQL 数据库中表中的一列（我使用的是 9.6 版）。我知道UTF8_UNICODE_CIMySQL上的排序规则，所以我尝试了：

CREATE TABLE thing (
    id    BIGINT PRIMARY KEY
   ,name  VARCHAR(120) NOT NULL COLLATE "UTF8_UNICODE_CI"
);

但我得到：

ERROR: collation "UTF8_UNICODE_CI" for encoding "UTF8" does not exist

Run Code Online (Sandbox Code Playgroud)

环顾四周，我发现pg_collation表格显示了排序规则，其中显示：

=# SELECT * from pg_collation;
 collname | collnamespace | collowner | collencoding | collcollate | collctype
----------+---------------+-----------+--------------+-------------+-----------
 default  |            11 |        10 |           -1 |             |
 C        |            11 |        10 |           -1 | C           | C
 POSIX    |            11 |        10 |           -1 | …

我在应用程序中的一个特别大的表上过度使用了 CITEXT 列。我想支持其中一些，因为如何触发所需索引的查找令人困惑。

我的问题是，我可以在不遇到任何重大困难的情况下做到这一点吗？如果我更改此设置，我是否需要重建这些字段上的任何索引？

朝这个方向发展会带来空间收益吗？

这些列不需要不区分大小写的查询。

我对该表进行了基于 2 列的计数，这些计数需要一个多小时。该表有 60 列。

我正在使用 Postgres 10.6。

我主要感兴趣的是，如果索引包含已从 CITEXT 更改为 VARCHAR 的列，是否需要重建索引。