postgresql计算的简单介绍

PostgreSQL开源免费企业级数据库用着比较爽的地方有哪些?

1),PostgreSQL是通用型数据库。

目前创新互联建站已为上千多家的企业提供了网站建设、域名、网页空间、网站托管维护、企业网站设计、通化县网站维护等服务,公司将坚持客户导向、应用为本的策略,正道将秉承"和谐、参与、激情"的文化,与客户和合作伙伴齐心协力一起成长,共同发展。

PG有着丰富的数据类型(数值、字符、时间、布尔、货币、枚举、网络地址、JSONB等等)和索引类型( B-tree、Hash、GiST、SP-GiST 、GIN 和 BRIN等 )。可以存储和计算大多数场景的业务数据,如 ERP、交易系统、财务系统涉及资金、客户等信息,数据不能丢失且业务逻辑复杂,选择 PostgreSQL 作为数据底层存储,一是可以帮助您在数据一致性前提下提供高可用性,二是可以用简单的编程实现复杂的业务逻辑 。适合各种OLTP和部分OLAP场景。

2),PostgreSQL数据库包含许多第三方插件。

如PostGIS等可以直接在数据库里进行地理位置相关的gis类存储和运算(LBS地理位置相关业务等O2O场景),其他的插件如Pg_stat_statements、uuid-ossp、pg_trgm、btree-gist插件、 pgcrypto加密等插件 。

3),中小型企业快速搭建 数据仓库和数据分析平台(TB级别)

PostgreSQL 提供丰富的数据类型和强大的计算能力,能够帮助您更简单搭建数据库仓库或大数据分析平台,为企业运营加分。

4),冷热分离

针对流水类的大表,PG可以使用分区表,线上保留热数据, 历史 数据存放在分区表里或者OSS等冷数据平台,冷热分离。

5),公有云支持度高如阿里云、腾讯云、华为云等公有云都有对应的RDS-PG产品,开箱即用,并提供技术支持。

OLTP:事务处理是PostgreSQL的本行

OLAP:ANSI SQL兼容,窗口函数,CTE,CUBE等高级分析功能,任意语言写UDF,citus分布式插件

流处理:PipelineDB扩展,Notify-Listen,物化视图,规则系统,灵活的存储过程与函数编写

时序数据:timescaledb时序数据库插件,分区表,BRIN索引

空间数据:PostGIS扩展(杀手锏),内建的几何类型支持,GiST索引。

搜索索引:全文搜索索引足以应对简单场景;丰富的索引类型,支持函数索引,条件索引

NoSQL:JSON,JSONB,XML,HStore原生支持,至NoSQL数据库的外部数据包装器

数据仓库:能平滑迁移至同属Pg生态的GreenPlum,DeepGreen,HAWK等,使用FDW进行ETL

PostgreSQL学习系列—EXPLAIN ANALYZE查询计划解读

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 t1.unique1 100 。Postgres查找与条件 unique1 100 匹配的行位置。此处不会返回行数据本身。成本估算 (cost=0.00..5.04 rows=101 width=0) 意味着Postgres预期将“花费” 任意计算单位的 5.04 来找到这些行。0.00是此节点开始工作的成本(在这种情况下,即为查询的启动时间)。 rows 是此索引扫描将返回的预估行数, width 是这些返回行的预估大小(以字节为单位)(0是因为这里只关心位置,而不是行数据的内容)。

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

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

当乘以之前计算的0.01值时,我们可以得到成本预期的大概时间(229.20 - 5.07)*0.01≈2.24ms,同时每行实际时间为除以4后的结果:0.526ms。这可能是因为成本估算是取的上限而不是取所有需读取的行,也或者因为Recheck条件总是生效。

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

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

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

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

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

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

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

翻译并编辑,原文出处:

postgresql里面怎么得到两个日期相差多少秒,或者多少分钟

PostgreSQL中直接用两个date(或者timestamp)值相减,其返回的是一个interval值,再有该interval值取出天数转换成分钟或秒数,再加上interval中分钟(和秒数)部分的值就可以了。

示例SQL:

select interval_value, date_part('day', interval_value) as day_value, date_part('day', interval_value) * 24 * 60 + date_part('minute', interval_value) as minutes

from (

select (current_timestamp - to_timestamp('2013-08-21 13:23', 'yyyy-mm-dd hh24:mi')) as interval_value

) s;


网站栏目:postgresql计算的简单介绍
网页URL:http://myzitong.com/article/dscgcec.html