我围绕将未处理的JSON文档存储在jsonb
中,然后使用(jsondoc->>'fieldname')
形式的字段访问表达式有选择地创建覆盖索引的思想来构建了整个应用程序,以确保所有必需的查询都可以作为仅索引扫描。存储原始json的想法非常吸引人,因为它删除了整个ETL(提取,转换,加载)层,该层一直是错误和操作麻烦的源头。
pgsql手册包含一个非常不幸的事实:
原则上,仅索引扫描可以与表达式索引一起使用。 例如,给定f(x)的索引,其中x是表列,则它 应该可以执行
SELECT f(x) FROM tab WHERE f(x) < 1;
作为仅索引扫描;如果f()是一个 昂贵的计算功能。 但是,PostgreSQL的计划者是 目前对于这种情况还不太聪明。它认为查询是 仅在需要所有列时才有可能通过仅索引扫描执行 通过查询可以从索引中获得。在此示例中,x不是 除了在上下文f(x)中是必需的,但计划者不会注意到 并得出结论,仅索引扫描是不可能的。如果 仅索引扫描似乎很值得,可以使用 通过声明索引在(f(x),x)上,第二个 该列不希望在实践中使用,仅用于 让计划者相信仅索引扫描是可能的。一个 另外的警告是,如果目标是避免重新计算f(x),则是 计划者不一定会匹配不在 索引列的可索引WHERE子句。通常会得到这个 在上面的简单查询中显示,但在 涉及联接。这些缺陷可能会在将来的版本中纠正 PostgreSQL。
我的问题非常具体:
如何在不复制索引中巨大的json负载的情况下将针对'x'描述的解决方法应用于jsonb
列?