小编Erw*_*ter的帖子

考虑：

with days as (select day::date
from generate_series(date '2013-01-01', date '2013-01-01' + 365, interval '1 day' day) day
) 
select 'Inspections'::text as data_label,
count(i.reporting_id) as daily_count, d.day as date_column
from days d
left join inspection i on i.close_case_date = d.day
group by d.day
order by d.day

这将返回一个如下所示的集合：

data_label | daily_count | date_column
Inspections    1           01/01/13
Inspections    2           01/02/13
Inspections    4           01/04/13
Inspections    8           01/06/13

请注意记录集中的 1 天和 2 天间隔。我需要生成一个用 0 填充的值的集合，如下所示：

data_label | daily_count | date_column
Inspections    1           01/01/13
Inspections …

我想知道这在 Postgres 中是否可行：

最好用一个人为的例子来解释：

create or replace function test_function(filter_param1 varchar default null
                                       , filter_param2 varchar default null)
  returns integer as
$$ 
declare
  stmt text;
  args varchar[];
  wher varchar[];
  retid integer;
begin
  if filter_param1 is not null then 
    array_append(args, filter_param1);
    array_append(wher, 'parameter_name = $1');
  end if;
  if filter_param2 is not null then 
    array_append(args, filter_param2);
    array_append(wher, 'parameter_name = $2');
  end if;

  stmt := 'select id from mytable where ' || array_to_string(wher, ' or ');
  execute stmt into retid using args;

  return retid; …

对于拥有超过 300,000 个帐户（并且还在增长）的大型 SAAS 应用程序（由 PostgreSql 9.4 提供支持），使用每个帐户的模式对数据进行分区与将所有数据放在一个模式中并使用外键进行分区的优缺点是什么？在查询中对其进行分区？

我知道过去 pg_dump 在处理许多模式时非常缓慢，但不确定今天是否如此。我也知道必须对所有模式进行数据库结构的任何更改。而且我知道从好的方面来说，将模式从一个物理服务器移动到另一个很容易，以及从备份中恢复模式，更不用说以这种方式对数据进行分区是有意义的。

那么我缺少的优点和缺点是什么？

为什么在 SELECT 列表中使用 Set Returning Function (SRF) 与在 FROM 子句中使用 SRF 在行为上存在差异？

例如，对于返回 2 行的简单 SRF：

CREATE OR REPLACE FUNCTION gen_series(out integer, out int)
  RETURNS SETOF record AS $$
  SELECT 1,1
  UNION
  SELECT 2,2;
$$ LANGUAGE SQL;

SELECT gen_series(); 返回两个单列行，每个行包含一条记录：

=>  gen_series 
------------
 (1,1)
 (2,2)
(2 rows)

而SELECT * FROM gen_series();返回扩展记录的两行：

=>  column1 | column2 
---------+---------
       1 |       1
       2 |       2
(2 rows)

相比之下，如果 SRF 返回单个列，则在 SELECT 或 FROM 子句中调用 SRF 没有区别。例如：

=> SELECT generate_series(1,2);
 generate_series 
----------------- …

Postgres 函数声明为波动性分类VOLATILE，STABLE或IMMUTABLE。众所周知，该项目对内置函数的这些标签非常严格。并且有充分的理由。突出的例子：表达式索引只允许IMMUTABLE函数并且那些必须是真正不可变的以避免错误的结果。

用户定义的函数仍然可以按照所有者的选择自由声明。手册建议：

为了获得最佳优化结果，您应该使用对它们有效的最严格的波动率类别来标记您的函数。

...并添加了大量可能因波动率标签不正确而出错的事情列表。

尽管如此，在某些情况下，伪造不变性是有道理的。大多数情况下，当您知道该函数实际上在您的范围内是不可变的。例子：

• PostgreSQL 是否支持“不区分重音”的排序规则？

除了对数据完整性的所有可能影响之外，对性能的影响是什么？人们可能认为声明一个函数IMMUTABLE只会对性能有益。是这样吗？

声明函数波动性会IMMUTABLE 损害性能吗？

让我们假设当前的 Postgres 10 来缩小范围，但所有最近的版本都很有趣。

double precision从( float8) 到numeric四舍五入到 15 个有效小数位的转换，从而丢失信息。显然，更高的精度是可能的。转换为bigint（对于其范围内的值）可以保留更高的精度：

SELECT f8          AS float8
     , f8::bigint  AS to_bigint
     , f8::numeric AS to_numeric
FROM  (
   VALUES
     ('8217316934885843456'::float8)
   , ('8217316934885843457')
   , ('8217316934885844479')
   , ('8217316934885844480')   
   , ('8217316934885845503')
   , ('8217316934885845584')   
   ) t(f8);

        float8         |      to_bigint      |     to_numeric      
-----------------------+---------------------+---------------------
 8.217316934885843e+18 | 8217316934885842944 | 8217316934885840000
 8.217316934885844e+18 | 8217316934885843968 | 8217316934885840000
 8.217316934885844e+18 | 8217316934885843968 | 8217316934885840000
 8.217316934885845e+18 | 8217316934885844992 | 8217316934885840000
 8.217316934885845e+18 | 8217316934885844992 | 8217316934885840000
 8.217316934885846e+18 | 8217316934885846016 | 8217316934885850000
(6 rows)

db<>在这里摆弄 …

PostgreSQL 9.2 引入了json字段类型。为什么以及何时应该使用它？它比文本字段有什么好处？

我以为有新的查询选项可用，但我没有看到任何选项。我错过了什么吗？

我运行PostgreSQL-9.2.4

是否可以从触发器调用 2 个函数？

假设以下触发器触发时，我有两个函数可以执行两个不同的表：

扳机：

CREATE TRIGGER start ON system_status FOR EACH ROW
WHEN ((new.event = start_task))
EXECUTE PROCEDURE ...()

功能 1：（ 当任务开始时 => 删除任何先前为此系统分配的下一个任务）

CREATE FUNCTION void_next_task() RETURNS trigger AS $$

BEGIN
  DELETE FROM tasks_status ts
  WHERE ts.system = NEW.system
  AND ts.event = 'next_task';
  RETURN NEW;
  END;

$$

LANGUAGE plpgsql

功能 2：（ 如果插入的组合task和system已经出现在表中=> 将此组合标记为任何较早的记录deleted）

CREATE FUNCTION void_dup_task() RETURNS trigger AS $$

BEGIN
  UPDATE system_status ss
  SET deleted = 'TRUE'
  WHERE ss.system …

我有一个包含从文本文档中提取的数据的表。数据存储在一个名为的列"CONTENT"中，我使用 GIN 创建了该索引：

CREATE INDEX "File_contentIndex"
  ON "File"
  USING gin
  (setweight(to_tsvector('english'::regconfig
           , COALESCE("CONTENT", ''::character varying)::text), 'C'::"char"));

我使用以下查询对表执行全文搜索：

SELECT "ITEMID",
  ts_rank(setweight(to_tsvector('english', coalesce("CONTENT",'')), 'C') , 
  plainto_tsquery('english', 'searchTerm')) AS "RANK"
FROM "File"
WHERE setweight(to_tsvector('english', coalesce("CONTENT",'')), 'C') 
  @@ plainto_tsquery('english', 'searchTerm')
ORDER BY "RANK" DESC
LIMIT 5;

File 表包含 250 000 行，每个"CONTENT"条目由一个随机单词和一个所有行都相同的文本字符串组成。

现在，当我搜索一个随机单词（在整个表中命中 1 个）时，查询运行得非常快（<100 毫秒）。但是，当我搜索出现在所有行中的单词时，查询运行速度非常慢（10 分钟或更长时间）。

EXPLAIN ANALYZE显示对于 1-hit 搜索，先执行位图索引扫描，然后执行位图堆扫描。对于慢速搜索，改为执行Seq Scan，这需要很长时间。

当然，在所有行中使用相同的数据是不现实的。但是由于我无法控制用户上传的文本文档，也无法控制他们执行的搜索，因此可能会出现类似的情况（搜索在 DB 中出现率很高的术语）。在这种情况下，如何提高搜索查询的性能？

运行 PostgreSQL 9.3.4

查询计划来自EXPLAIN ANALYZE：

快速搜索（在 DB …

是否可以在 Postgres 中创建某种分组链？假设我有以下图表：

CREATE TABLE foo AS
SELECT row_number() OVER () AS id, *
FROM ( VALUES
  ( 'X', 'D', 'G', 'P' ),
  ( 'F', 'D', 'L', 'M' ),
  ( 'X', 'N', 'R', 'S' ),
  ( 'Y', 'I', 'W', NULL ),
  ( 'U', 'Z', 'E', NULL )
) AS f(a,b,c,d);

id | a | b | c | d
------------------
 1 | X | D | G | P
 2 | F | D | L | M
 3 | …