PostGreSQL Json数据存储和条件查询

创建一张志愿者的数据表,记录每批参加志愿活动的人员名单。其中人员信息保存在json字段中。

知识点 : (1)postgresql中自增长的id创建。 (2)修改表字段语句。 (3)标准sql中table name ,column name双引号。

查询年龄大于等于25岁以上的志愿者

知识点 : (1)查询结果的的row number生成。 (2)获取json对象中的子对象。 (3)转换json对象属性的数据类型。

一、使用EXPLAIN：

PostgreSQL为每个查询都生成一个查询规划，因为选择正确的查询路径对性能的影响是极为关键的。PostgreSQL本身已经包含了一个规划器用于寻找最优规划，我们可以通过使用EXPLAIN命令来查看规划器为每个查询生成的查询规划。

PostgreSQL中生成的查询规划是由1到n个规划节点构成的规划树，其中最底层的节点为表扫描节点，用于从数据表中返回检索出的数据行。然而，不同

的扫描节点类型代表着不同的表访问模式，如：顺序扫描、索引扫描，以及位图索引扫描等。如果查询仍然需要连接、聚集、排序，或者是对原始行的其它 *** 作，那

么就会在扫描节点"之上"有其它额外的节点。并且这些 *** 作通常都有多种方法，因此在这些位置也有可能出现不同的节点类型。EXPLAIN将为规划树中的每

个节点都输出一行信息，显示基本的节点类型和规划器为执行这个规划节点计算出的预计开销值。第一行(最上层的节点)是对该规划的总执行开销的预计，这个数

值就是规划器试图最小化的数值。

这里有一个简单的例子，如下：

复制代码 代码如下:

EXPLAIN SELECT FROM tenk1;

QUERY PLAN

-------------------------------------------------------------

Seq Scan on tenk1 (cost=00045800 rows=10000 width=244)

EXPLAIN引用的数据是：

1) 预计的启动开销(在输出扫描开始之前消耗的时间，比如在一个排序节点里做排续的时间)。

2) 预计的总开销。

3) 预计的该规划节点输出的行数。

4) 预计的该规划节点的行平均宽度(单位：字节)。

这里开销(cost)的计算单位是磁盘页面的存取数量，如10将表示一次顺序的磁盘页面读取。其中上层节点的开销将包括其所有子节点的开销。这里的输出

行数(rows)并不是规划节点处理/扫描的行数，通常会更少一些。一般而言，顶层的行预计数量会更接近于查询实际返回的行数。

现在我们执行下面基于系统表的查询：

复制代码 代码如下:

SELECT relpages, reltuples FROM pg_class WHERE relname = 'tenk1';

从查询结果中可以看出tenk1表占有358个磁盘页面和10000条记录，然而为了计算cost的值，我们仍然需要知道另外一个系统参数值。

复制代码 代码如下:

postgres=# show cpu_tuple_cost;

cpu_tuple_cost

----------------

001

(1 row)

cost = 358(磁盘页面数) + 10000(行数) 001(cpu_tuple_cost系统参数值)

下面我们再来看一个带有WHERE条件的查询规划。

复制代码 代码如下:

EXPLAIN SELECT FROM tenk1 WHERE unique1 < 7000;

QUERY PLAN

------------------------------------------------------------

Seq Scan on tenk1 (cost=00048300 rows=7033 width=244)

Filter: (unique1 < 7000)

EXPLAIN的输出显示，WHERE子句被当作一个"filter"应用，这表示该规划节点将扫描表中的每一行数据，之后再判定它们是否符合过滤的条

件，最后仅输出通过过滤条件的行数。这里由于WHERE子句的存在，预计的输出行数减少了。即便如此，扫描仍将访问所有10000行数据，因此开销并没有

真正降低，实际上它还增加了一些因数据过滤而产生的额外CPU开销。

上面的数据只是一个预计数字，即使是在每次执行ANALYZE命令之后也会随之改变，因为ANALYZE生成的统计数据是通过从该表中随机抽取的样本计算的。

如果我们将上面查询的条件设置的更为严格一些的话，将会得到不同的查询规划，如：

复制代码 代码如下:

EXPLAIN SELECT FROM tenk1 WHERE unique1 < 100;

QUERY PLAN

------------------------------------------------------------------------------

Bitmap Heap Scan on tenk1 (cost=23723235 rows=106 width=244)

Recheck Cond: (unique1 < 100)

-> Bitmap Index Scan on tenk1_unique1 (cost=000237 rows=106 width=0)

Index Cond: (unique1 < 100)

这里，规划器决定使用两步规划，最内层的规划节点访问一个索引，找出匹配索引条件的行的位置，然后上层规划节点再从表里读取这些行。单独地读取数据行比顺

序地读取它们的开销要高很多，但是因为并非访问该表的所有磁盘页面，因此该方法的开销仍然比一次顺序扫描的开销要少。这里使用两层规划的原因是因为上层规

划节点把通过索引检索出来的行的物理位置先进行排序，这样可以最小化单独读取磁盘页面的开销。节点名称里面提到的"位图(bitmap)"是进行排序的机

制。

现在我们还可以将WHERE的条件设置的更加严格，如：

复制代码 代码如下:

EXPLAIN SELECT FROM tenk1 WHERE unique1 < 3;

QUERY PLAN

------------------------------------------------------------------------------

Index Scan using tenk1_unique1 on tenk1 (cost=0001000 rows=2 width=244)

Index Cond: (unique1 < 3)

在该SQL中，表的数据行是以索引的顺序来读取的，这样就会令读取它们的开销变得更大，然而事实上这里将要获取的行数却少得可怜，因此没有必要在基于行的物理位置进行排序了。

现在我们需要向WHERE子句增加另外一个条件，如：

复制代码 代码如下:

EXPLAIN SELECT FROM tenk1 WHERE unique1 < 3 AND stringu1 = 'xxx';

QUERY PLAN

------------------------------------------------------------------------------

Index Scan using tenk1_unique1 on tenk1 (cost=0001001 rows=1 width=244)

Index Cond: (unique1 < 3)

Filter: (stringu1 = 'xxx'::name)

新增的过滤条件stringu1 = 'xxx'只是减少了预计输出的行数，但是并没有减少实际开销，因为我们仍然需要访问相同数量的数据行。而该条件并没有作为一个索引条件，而是被当成对索引结果的过滤条件来看待。

如果WHERE条件里有多个字段存在索引，那么规划器可能会使用索引的AND或OR的组合，如：

复制代码 代码如下:

EXPLAIN SELECT FROM tenk1 WHERE unique1 < 100 AND unique2 > 9000;

QUERY PLAN

-------------------------------------------------------------------------------------

Bitmap Heap Scan on tenk1 (cost=11274911 rows=11 width=244)

Recheck Cond: ((unique1 < 100) AND (unique2 > 9000))

-> BitmapAnd (cost=11271127 rows=11 width=0)

-> Bitmap Index Scan on tenk1_unique1 (cost=000237 rows=106 width=0)

Index Cond: (unique1 < 100)

-> Bitmap Index Scan on tenk1_unique2 (cost=000865 rows=1042 width=0)

Index Cond: (unique2 > 9000)

这样的结果将会导致访问两个索引，与只使用一个索引，而把另外一个条件只当作过滤器相比，这个方法未必是更优。

现在让我们来看一下基于索引字段进行表连接的查询规划，如：

复制代码 代码如下:

EXPLAIN SELECT FROM tenk1 t1, tenk2 t2 WHERE t1unique1 < 100 AND t1unique2 = t2unique2;

QUERY PLAN

--------------------------------------------------------------------------------------

Nested Loop (cost=23755311 rows=106 width=488)

-> Bitmap Heap Scan on tenk1 t1 (cost=23723235 rows=106 width=244)

Recheck Cond: (unique1 < 100)

-> Bitmap Index Scan on tenk1_unique1 (cost=000237 rows=106 width=0)

Index Cond: (unique1 < 100)

-> Index Scan using tenk2_unique2 on tenk2 t2 (cost=000301 rows=1 width=244)

Index Cond: ("outer"unique2 = t2unique2)

从查询规划中可以看出(Nested

Loop)该查询语句使用了嵌套循环。外层的扫描是一个位图索引，因此其开销与行计数和之前查询的开销是相同的，这是因为条件unique1 <

100发挥了作用。 这个时候t1unique2 =

t2unique2条件子句还没有产生什么作用，因此它不会影响外层扫描的行计数。然而对于内层扫描而言，当前外层扫描的数据行将被插入到内层索引扫描

中，并生成类似的条件t2unique2 = constant。所以，内层扫描将得到和EXPLAIN SELECT FROM tenk2

WHERE unique2 = 42一样的计划和开销。最后，以外层扫描的开销为基础设置循环节点的开销，再加上每个外层行的一个迭代(这里是 106

301)，以及连接处理需要的一点点CPU时间。

如果不想使用嵌套循环的方式来规划上面的查询，那么我们可以通过执行以下系统设置，以关闭嵌套循环，如：

复制代码 代码如下:

SET enable_nestloop = off;

EXPLAIN SELECT FROM tenk1 t1, tenk2 t2 WHERE t1unique1 < 100 AND t1unique2 = t2unique2;

QUERY PLAN

------------------------------------------------------------------------------------------

Hash Join (cost=2326174167 rows=106 width=488)

Hash Cond: ("outer"unique2 = "inner"unique2)

-> Seq Scan on tenk2 t2 (cost=00045800 rows=10000 width=244)

-> Hash (cost=2323523235 rows=106 width=244)

-> Bitmap Heap Scan on tenk1 t1 (cost=23723235 rows=106 width=244)

Recheck Cond: (unique1 < 100)

-> Bitmap Index Scan on tenk1_unique1 (cost=000237 rows=106 width=0)

Index Cond: (unique1 < 100)

这个规划仍然试图用同样的索引扫描从tenk1里面取出符合要求的100行，并把它们存储在内存中的散列(哈希)表里，然后对tenk2做一次全表顺序扫

描，并为每一条tenk2中的记录查询散列(哈希)表，寻找可能匹配t1unique2 =

t2unique2的行。读取tenk1和建立散列表是此散列联接的全部启动开销，因为我们在开始读取tenk2之前不可能获得任何输出行。

此外，我们还可以用EXPLAIN ANALYZE命令检查规划器预估值的准确性。这个命令将先执行该查询，然后显示每个规划节点内实际运行时间，以及单纯EXPLAIN命令显示的预计开销，如：

复制代码 代码如下:

EXPLAIN ANALYZE SELECT FROM tenk1 t1, tenk2 t2 WHERE t1unique1 < 100 AND t1unique2 = t2unique2;

QUERY PLAN

----------------------------------------------------------------------------------------------------------------------------------

Nested Loop (cost=23755311 rows=106 width=488) (actual time=139212700 rows=100 loops=1)

-> Bitmap Heap Scan on tenk1 t1 (cost=23723235 rows=106 width=244) (actual time=08782367 rows=100 loops=1)

Recheck Cond: (unique1 < 100)

-> Bitmap Index Scan on tenk1_unique1 (cost=000237

rows=106 width=0) (actual time=05460546 rows=100 loops=1)

Index Cond: (unique1 < 100)

-> Index Scan using tenk2_unique2 on tenk2 t2

(cost=000301 rows=1 width=244) (actual time=00670078 rows=1

loops=100)

Index Cond: ("outer"unique2 = t2unique2)

Total runtime: 14452 ms

注意"actual time"数值是以真实时间的毫秒来计算的，而"cost"预估值是以磁盘页面读取数量来计算的，所以它们很可能是不一致的。然而我们需要关注的只是两组数据的比值是否一致。

在一些查询规划里，一个子规划节点很可能会运行多次，如之前的嵌套循环规划，内层的索引扫描会为每个外层行执行一次。在这种情况下，"loops"将报告

该节点执行的总次数，而显示的实际时间和行数目则是每次执行的平均值。这么做的原因是令这些真实数值与开销预计显示的数值更具可比性。如果想获得该节点所

花费的时间总数，计算方式是用该值乘以"loops"值。

EXPLAIN ANALYZE显示的"Total runtime"包括执行器启动和关闭的时间，以及结果行处理的时间，但是它并不包括分析、重写或者规划的时间。

如果EXPLAIN命令仅能用于测试环境，而不能用于真实环境，那它就什么用都没有。比如，在一个数据较少的表上执行EXPLAIN，它不能适用于数量很

多的大表，因为规划器的开销计算不是线性的，因此它很可能对大些或者小些的表选择不同的规划。一个极端的例子是一个只占据一个磁盘页面的表，在这样的表

上，不管它有没有索引可以使用，你几乎都总是得到顺序扫描规划。规划器知道不管在任何情况下它都要进行一个磁盘页面的读取，所以再增加几个磁盘页面读取用

以查找索引是毫无意义的。

二、批量数据插入：

有以下几种方法用于优化数据的批量插入。

1 关闭自动提交：

在批量插入数据时，如果每条数据都被自动提交，当中途出现系统故障时，不仅不能保障本次批量插入的数据一致性，而且由于有多次提交 *** 作的发生，整个插入效

率也会受到很大的打击。解决方法是，关闭系统的自动提交，并且在插入开始之前，显示的执行begin

transaction命令，在全部插入 *** 作完成之后再执行commit命令提交所有的插入 *** 作。

2 使用COPY：

使用COPY在一条命令里装载所有记录，而不是一系列的INSERT命令。COPY命令是为装载数量巨大的数据行优化过的，它不像INSERT命令那样灵

活，但是在装载大量数据时，系统开销也要少很多。因为COPY是单条命令，因此在填充表的时就没有必要关闭自动提交了。

3 删除索引：

如果你正在装载一个新创建的表，最快的方法是创建表，用COPY批量装载，然后创建表需要的任何索引。因为在已存在数据的表上创建索引比维护逐行增加要快。当然在缺少索引期间，其它有关该表的查询 *** 作的性能将会受到一定的影响，唯一性约束也有可能遭到破坏。

4 删除外键约束：

和索引一样，"批量地"检查外键约束比一行行检查更加高效。因此，我们可以先删除外键约束，装载数据，然后在重建约束。

5 增大maintenance_work_mem：

在装载大量数据时，临时增大maintenance_work_mem系统变量的值可以改进性能。这个系统参数可以提高CREATE

INDEX命令和ALTER TABLE ADD FOREIGN KEY命令的执行效率，但是它不会对COPY *** 作本身产生多大的影响。

6 增大checkpoint_segments：

临时增大checkpoint_segments系统变量的值也可以提高大量数据装载的效率。这是因为在向PostgreSQL装载大量数据时，将会导致

检查点 *** 作(由系统变量checkpoint_timeout声明)比平时更加频繁的发生。在每次检查点发生时，所有的脏数据都必须flush到磁盘上。

通过提高checkpoint_segments变量的值，可以有效的减少检查点的数目。

7 事后运行ANALYZE：

在增加或者更新了大量数据之后，应该立即运行ANALYZE命令，这样可以保证规划器得到基于该表的最新数据统计。换句话说，如果没有统计数据或者统计数据太过陈旧，那么规划器很可能会选择一个较差的查询规划，从而导致查询效率过于低下。

如何使用直连方式连接数据库

1，ArcGIS101统一了数据库连接，也就是不区分是空间数据库连接还是通过OLEDB方式的关系型数据库连接

2，在Catalog中只能采用直连方式；

3，ArcGIS101版本中，Esri提供的安装介质不在包含Postgresql（以前的是包含的）；

4，安装Postgresql，官方给的软件要求是64位数，而且所有的企业级数据库都是64位(这应该和Server有关系吧，因为Server101是纯64位,在桌面软件的目录中给出的几个dll都是64位，这几个dll后面会用到，官方给的软件需求如下：

Database

SupportedOperatingSystems

MinimumOSVersion

MaximumOSVersion

PostgreSQL905(64-bit)

RedHatEnterpriseLinuxServer5(64-bit)

Update7

RedHatEnterpriseLinuxServer6(64-bit)

SUSELinuxEnterpriseServer11(64-bit)

SP1

WindowsServer2003Standard,Enterprise,andDatacenter(64-bit[EM64T])

SP2

SP2

WindowsServer2008R2Standard,Enterprise,andDatacenter(64-bit[EM64T])

SP1

5，配置PostgreSQL的客户端。因为直连方式要求ArcSDE的客户端必须安装数据库的客户端类库，所以首先需要获取PostgreSQL的客户端。ArcGISDesktop是32位软件，需要的是32位的PostgreSQL类库。找到PostgreSQL的客户端，或者在别的机器上将32位的libeay32dll,libiconv-2dll,libintl-8dll,libpqdll,andssleay32dll文件拷贝到Desktop安装目录的bin目录下;

6，拷贝st_geometrydll，将Desktop安装目录下的/PostgreSQL/Windows64(看到64了吧)目录下，拷贝st_geometrydll文件到PostgreSQL的lib目录。在PostgreSQL中创建Geodatabase时必须用到此类库；

7，配置pg_hbaconf，修改PostgreSQ的pg_hbaconf文件，添加“hostallall0000/0md5”（关于该文件的配置，可以参阅相关资料）；

8，在安装完SDE后，发现没有以往的post界面，在101中，对于创建企业级Geodatabase都采用工具箱中提供的工具，换句话说，以前的post被Toolbox中的一堆工具替代；

9，创建地理数据库

101在创建地理数据库的时候，提供了三个，Oracle，SQLServer和Postgresql，我们用这个工具创建地理数据库，这个过程相当于早起的POST过程，创建数据库并写入一堆系统表等

针对上面的select 创建的视图获取到基础表的所有字段内容，我们做一个测试，不难发现在基础表上新增字段后，对已建的视图是没有影响的，新的字段内容并不会自动添加到视图上。

对于被视图引用的字段，是不允许被修改类型的，如果需要修改类型，需要先删掉视图，修改后再重建视图。

可以看到修改基础表的字段名，对应视图的的字段名称没有自动同步过来，是没有生效的。

同样，被视图引用的字段，是不允许被修改字段长度的。

除了以上所提到的问题，还有其他的内容，欢迎遇到问题的pger前来补充。

首先知道substring函数在PostgreSQL中的作用。在这段SQ语句中，substring是使用的substring(txt from reg)的形式，其中, txt是要进行正则匹配的源字符串，reg是匹配的正则表达式。如此，我们大概可以知道：这段代码的then其实就是用information进行一些正则表达式的匹配，然后获取匹配后的那段字符串。

这段代码中一共有3个substring函数调用，而执行的顺序则与它们出现的顺序相反，首先执行的是:

substring(information from E':step_1: \\([0 -9]+)' )

它获得匹配step_1: 后面所跟的数字；假设information为:step_1: 1234a, 那么获得的就是1234；

接下来为第二substring, 它是用information来匹配上面获得的数字嵌入":&"和":step_1:"的那段内容；

而最后一个substring，则是匹配第二个获得的字串，其中前为“loan_purpose: ”接下来为非换行符号的那部分字串(即获得以“loan_purpose: ”开始的所有非换行字符，遇到换行符就终止，不包括"loan_purpose: ")。

一个例子:

select substring( substring( information FROM': &' ||  substring(information from E':step_1: 

\\([0-9]+)'

) ||':step_1:') 

from E'loan_purpose: ([^\n]+)')

from (select 'start here: &1234loan_purpose: Hello World:step_1: 1234end'::character varying as information)

s

运行结果如图，

1、首先登录sql server managment。

2、然后在打开的页面中，使用鼠标右键单击，选择活动监视器。

3、然后在打开页面中，找到最近耗费大量资源的查询。

4、点击下三角按钮，看执行次数最大的。

5、最后右键单击选择编辑查询文本，查看sql语句，就完成了。

PostgreSQL命令 EXPLAIN ANALYZE 是日常工作中了解和优化SQL查询过程所用到的最强大工具，后接如 SELECT ， UPDATE 或者 DELETE 等SQL语句，命令执行后并不返回数据，而是输出查询计划，详细说明规划器通过何种方式来执行给定的SQL语句。

下面是从 Postgres Using EXPLAIN 提取的查询：

它生成的查询计划：

Postgres构建了一个规划节点的树结构，以表示所采取的不同 *** 作，其中root根和每个 -> 指向其中一个 *** 作。在某些情况下， EXPLAIN ANALYZE 会提供除执行时间和行数之外的额外执行统计信息，例如上面例子中的 Sort 及 Hash 。除第一个没有 -> 的行之外的任何行都是诸如此类的信息，因此查询的结构是：

每个树分支代表子动作，从里到外以确定哪个是“第一个”发生（尽管同一级别的节点顺序可能不同）。

在 tenk_unique1 索引上执行的第一个 *** 作是 Bitmap Index Scan ：

这对应于SQL WHERE t1unique1 < 100 。Postgres查找与条件 unique1 < 100 匹配的行位置。此处不会返回行数据本身。成本估算 (cost=000504 rows=101 width=0) 意味着Postgres预期将“花费” 任意计算单位的 504 来找到这些行。000是此节点开始工作的成本（在这种情况下，即为查询的启动时间）。 rows 是此索引扫描将返回的预估行数， width 是这些返回行的预估大小（以字节为单位）（0是因为这里只关心位置，而不是行数据的内容）。

因为使用了 ANALYZE 选项运行 EXPLAIN ，所以查询被实际执行并捕获了计时信息。 (actual time=00490049 rows=100 loops=1) 表示索引扫描执行了1次（ loops 值），结果返回了100行，实际时间是0 如果节点执行了多次，实际时间是每次迭代的平均值，可以将该值乘以循环次数以获取实际时间。基于成本的最小/最大时间的概念，范围值也可能会有所不同。通过这些值，我们可以为该查询生成一个成本比率，每个成本单位为0049ms / 504单位≈001ms/单位。

索引扫描的结果将传递给 Bitmap Heap Scan *** 作。在此节点中，Postgres将获取别名为t1的tenk1表中行的位置，根据 unique1 < 100 条件筛选并获取行。

当乘以之前计算的001值时，我们可以得到成本预期的大概时间（22920 - 507）001≈224ms，同时每行实际时间为除以4后的结果：0526ms。这可能是因为成本估算是取的上限而不是取所有需读取的行，也或者因为Recheck条件总是生效。

和表顺序读取行（a Seq Scan ）相比， Bitmap Index Scan 和 Bitmap Heap Scan 关联 *** 作成本要昂贵得多，但是因为在这种情况下只需要访问相对较少的行，所以关联 *** 作最终会变得更快。通过在获取行之前将行按照物理顺序排序来进一步加速，这会将单独获取的成本降到最低。节点名称中的“Bitmap”完成了排序 *** 作。

表扫描的结果（tenk1表中满足 unique1 < 100 条件的那些行）将在读取时被插入到内存的哈希表中。正如我们从成本中看到的那样，这根本不需要时间。

哈希节点包括散列桶(hash buckets)和批次数(batches)相关的信息，以及内存使用峰值情况。如果批次> 1，则还会包括未显示的磁盘使用信息。内存占用在100行 244字节= 244 kB时是有意义的，它非常接近28kB，我们假定这是哈希键本身所占用的内存。

接下来，Postgres从别名为t2的tenk2表读取所有的10000行，并根据tenk1表行的Hash检查它们。散列连接意味着将一个表的行输入到内存中的散列（先前的 *** 作中已构建），之后扫描另一个表的行，并根据散列表探测其值以进行匹配。在第二行可以看到“匹配”的条件， Hash Cond: (t2unique2 = t1unique2) 。请注意，因为查询是从tenk1和tenk2中选择所有值，所以在散列连接期间每行的宽度加倍。

现在已经收集了满足条件的所有行，可以对结果集进行排序 Sort Key: t1fivethous 。

Sort节点包含排序算法 quicksort 相关的信息 ，排序是在内存中还是在磁盘上完成（这将极大地影响速度），以及排序所需的内存/磁盘空间量。

熟悉如何解读查询计划会非常有助于优化查询。例如，Seq Scan节点通常表示添加索引的必要性，读取速度可能要快得多。

翻译并编辑，原文出处： >

注意：键值对的键必须使用双引号

查询JSONB中字段

根据某一键值查找

示例：

functions-json

右 *** 作符为int： 获取JSON数组元素（索引从0开始）

右 *** 作符为text： 通过键获取json值

右 *** 作符为int： 获取JSON数组元素为text

右 *** 作符为text： 通过键获取json值为text

右 *** 作符为: text[] , 在指定的路径获取JSON对象。

即在获取 ab 的值

右 *** 作符为: text[] , 在指定的路径获取JSON对象为text

即获取 a[2] 的值并转为text

右 *** 作数的类型： jsonb , 左侧的JSONB的是否包含右侧的

右 *** 作数的类型： jsonb , 右侧的JSONB的是否包含左侧的

右 *** 作符: text , 该字符串是否存在于json的顶级key中

右 *** 作符： text[] ，所有这些元素是否存都在于json的顶级key中

右 *** 作符: jsonb , 拼接两个 jsonb 生成一个新的 jsonb

右 *** 作符： text ，从左 *** 作数中删除K/V或者字符串元素。

右 *** 作符： int ， 删除指定索引的元素（负数表示从结尾开始）

右 *** 作符： text[] ， 删除字段或指定路径的元素

json(jsonb)中的CRUD

添加jsonb的字段

删除jsonb的某字段

以上就是关于PostGreSQL Json数据存储和条件查询全部的内容，包括:PostGreSQL Json数据存储和条件查询、如何提高postgresql查询性能、arcgis数据库用的什么数据库系统(arcgis数据库建库)等相关内容解答，如果想了解更多相关内容，可以关注我们，你们的支持是我们更新的动力！