我意志的许多Oracle DBA王人在学习PG在线av，无论是国内如故海外。数据库多元化发展，拥抱开源是一个趋势性的东西。关于Oracle DBA来说，PG这么的学院派数据库不管从架构上如故从功能上王人有一定的相似性，学习起来会感到比较胜切。诚然如斯，PG数据库和Oracle是相反很大的，哪怕一些看似近似的倡导，因为两种数据库的竣事形式不同，在施行诈欺中的相反很大。今天我就通过几个容易激发歪曲的问题，给公共提个醒。
也曾有东说念主和我扣问PG的WORK_MEM，他以为PG的WORK_MEM就有点近似于Oracle的PGA手工治理。粗粗一看，好像还果然像，不外要是你统统按照使用Oracle PGA的*_area_size相通来使用WORK_MEM，那是日夕会遭逢坑的。咱们知说念，PG数据库浮泛HASH ANTI JION算子，因此在处理一些NOT IN类型的子查询时通常使用Filter算子，这个算子通过对联查询的收尾集生成HASH表，然后由外在来轮回探伤，最终完成NOT IN过滤。
这种推论规划，诚然外在比较大的时刻收尾不高，不外总体推论性能大无数情况下如故能经受的。要是咱们不竭加大T2表恰当条款的收尾集的数据量，再来推论一下这条SQL。
文爱电报群
当内表的收尾集需要生成的HASH表的大小大于WORK_MEM的时刻，推论规划竟然变了。在不使用HASH表的情况下，这条SQL的推论时刻恶化到75146毫秒。我的测试环境是PG 14，起码在这个现时使用量比较大的版块中，PG是不会使用多个WORK_MEM，或者接管近似Oracle的2-PASS HASH TABLE的机制来动态处理的。在这种情况下，咱们只可通过会话级临时加大WORK_MEM来处理问题。
上头的例子不错看出，当WORK_MEM加大到128MB的时刻，又开动使用HASH表了，推论收尾也追念了。
对Oracle DBA的第一个领会挑战是，WORK_MEM确立的变嫌会影响SQL的推论规划。可能目下的Oracle DBA还是健忘PGA手工治理了，在当年纪业器内存资源有限，磁盘IO性能极差的年代里，确立合理的PGA参数并非易事。目下边对PG，可能这个问题会愈加严峻，在一些大型重要企业诈欺系统中，确立恰当的WORK_MEM的紧迫性比PGA手工治理期间愈加紧迫。确立过大的WORK_MEM，有可能导致物理内存不及，确立太小，会让有些SQL跑不出来。关于稀奇的SQL，确立会话级的WORK_MEM可能是更好的处理有运筹帷幄。
第二个容易让学习PG的Oracle DBA困惑的是CURSOR SHARING机制。在Oracle数据库中，CURSOR SHARING的性能十分重要，关于高并发的诈欺来说，这少量尤为紧迫。要是硬理会过多，会破钞无用要的CPU资源，严重时会激发性能危急。与Oracle不同的是，PG诚然学习了Oracle的CURSOR分享机制，接管了一种近似的活动来处理分享CURSOR和幸免多种最优推论规划导致的SQL性能问题。PG莫得近似Oracle的分享池机制，因此不成能有全局CURSOR的倡导。PG的CURSOR分享是会话级的，不是实例级的。在PG的一个会话中，一条SQL的前五次推论，每次王人会从头生成推论规划，要是前五次编译发现有在通用推论规划，那么这个通用推论规划就会被分享。
与Oracle的CURSOR SHARING比较，这种机制要难治理多了，关于近似的SQL，很可能因为绑定变量的不同，导致不同的会话中某条SQL 的推论规划是不同的，推论收尾存在很大的相反。在Oracle数据库中要是咱们发现某个SQL的推论规划因为BIND PEEKING 等方面的原因发生了诞妄，那么咱们在分享池中将这个CURSOR PURGE掉，下一次SQL被推论时就会从头生成推论规划，大约率会改造当年的诞妄了。不外在PG里，因为莫得全局分享CURSOR而变得十分费劲了。天然通过对关联表作念DDL会让悉数会话的推论规划失效，或者杀掉某个存在问题的会话不错处理这个问题。
施行上在一个并发终点高的PG数据库中要对推论往往的表作念DDL，其反作用也远浩大于Oracle数据库，出人意外的SQL理会风暴很可能打爆事业器的CPU，从而激发性能故障。
基于上头的一些问题，动作DBA，应该尽可能为我方的PG数据库苦求更多的CPU和物理内存资源。在事业器资源相对有余的系统中，上述两个问题带来的影响王人不错得回一定经由的规矩。
今天的时刻干系，咱们先扣问这两个问题，要是PG数据库承担了高负载的重要业务系统，那么DBA也许果然会在坐褥环境中遭逢这些问题，但愿今天的著述关于正在学习或者转型到PG数据库的Oracle DBA有所匡助。也给这些DBA提个醒，有些名义上的倡导，施行上PG和Oracle是有施行相反的。比如流复制VS DATAGUARD ，WAL VS REDO，分区表在线av，CHECKPOINT，等等等等。
