189 8069 5689
1. 查询表名称
创新互联为您提适合企业的网站设计 让您的网站在搜索引擎具有高度排名，让您的网站具备超强的网络竞争力！结合企业自身，进行网站设计及把握，最后结合企业文化和具体宗旨等，才能创作出一份性化解决方案。从网站策划到做网站、成都做网站， 我们的网页设计师为您提供的解决方案。
在psql状态下查询表名称：\dt
SQL方式查看表名称：
SELECT tablename FROM pg_tables;
SELECT viewname FROM pg_views
WHERE schemaname ='public'
PostgreSQL获取数据库中所有view名 视图
SELECT viewname FROM pg_views
WHERE schemaname ='public'
2. 查询表结构
在psql状态下查询表结构 \d tablename
SQL方式查看表结构
SELECT a.attnum,
a.attname AS field,
t.typname AS type,
a.attlen AS length,
a.atttypmod AS lengthvar,
a.attnotnull AS notnull,
b.description AS comment
FROM pg_class c,
pg_attribute a
LEFT OUTER JOIN pg_description b ON a.attrelid=b.objoid AND a.attnum = b.objsubid,
pg_type t
WHERE c.relname = 'udoc_saldiscount'
and a.attnum 0
and a.attrelid = c.oid
and a.atttypid = t.oid
ORDER BY a.attnum;
扩展资料：
PostgreSQL存储系统是由以下几个子模块所构成的：
1）页面管理子模块：对PostgreSQL缓冲区页面的组织结构进行定义以及提供页面操作的方法。
2）缓冲区管理子模块：管理PostgreSQL的缓冲区，包括本地缓冲区和共享缓冲区。
3）存储设备管理子模块：数据库记录是存储在存储介质上的，存储设备管理子模块将屏蔽不同物理存储设备（块设备，流设备）接口函数的差异，向上层缓冲区管理子模块提供统一的访问接口函数。
4）文件管理子模块：一般的操作系统对一个进程允许打开的文件数是有限制的，而PostgreSQL服务器有些时候需要打开的文件数是很多的，因此PostgreSQL文件管理子模块自身为了突破这个瓶颈，封装了文件的读写操作。
这可能是服务器崩溃了，看看是不是有病毒打开了太多的端口，
netstat -na
一般不上网时十几个是正常的，几十个就有问题了。5432端口是postgresql默认端口。
另外，检查一下服务器日志，还有windows日志，看看是不是有异常。postgresql默认是永远打开的，我们遇到过的情况是病毒占用了 5432 端口，导致postgresql 无法监听，和你的略有区别。看看日志里面有没有 postgres.exe 的信息。
一、索引的类型：
PostgreSQL提供了多种索引类型：B-Tree、Hash、GiST和GIN，由于它们使用了不同的算法，因此每种索引类型都有其适合的查询类型，缺省时，CREATE INDEX命令将创建B-Tree索引。
1. B-Tree:
CREATE TABLE test1 (
id integer,
content varchar
);
CREATE INDEX test1_id_index ON test1 (id);
B-Tree索引主要用于等于和范围查询，特别是当索引列包含操作符" 、=和"作为查询条件时，PostgreSQL的查询规划器都会考虑使用B-Tree索引。在使用BETWEEN、IN、IS NULL和IS NOT NULL的查询中，PostgreSQL也可以使用B-Tree索引。然而对于基于模式匹配操作符的查询，如LIKE、ILIKE、~和 ~*，仅当模式存在一个常量，且该常量位于模式字符串的开头时，如col LIKE 'foo%'或col ~ '^foo'，索引才会生效，否则将会执行全表扫描，如：col LIKE '%bar'。
2. Hash：
CREATE INDEX name ON table USING hash (column);
散列(Hash)索引只能处理简单的等于比较。当索引列使用等于操作符进行比较时，查询规划器会考虑使用散列索引。
这里需要额外说明的是，PostgreSQL散列索引的性能不比B-Tree索引强，但是散列索引的尺寸和构造时间则更差。另外，由于散列索引操作目前没有记录WAL日志，因此一旦发生了数据库崩溃，我们将不得不用REINDEX重建散列索引。
3. GiST：
GiST索引不是一种单独的索引类型，而是一种架构，可以在该架构上实现很多不同的索引策略。从而可以使GiST索引根据不同的索引策略，而使用特定的操作符类型。
4. GIN：
GIN索引是反转索引，它可以处理包含多个键的值(比如数组)。与GiST类似，GIN同样支持用户定义的索引策略，从而可以使GIN索引根据不同的索引策略，而使用特定的操作符类型。作为示例，PostgreSQL的标准发布中包含了用于一维数组的GIN操作符类型，如：、=、等。
二、复合索引：
PostgreSQL中的索引可以定义在数据表的多个字段上，如：
CREATE TABLE test2 (
major int,
minor int,
name varchar
}
CREATE INDEX test2_mm_idx ON test2 (major, minor);
1. B-Tree类型的复合索引：
在B-Tree类型的复合索引中，该索引字段的任意子集均可用于查询条件，不过，只有当复合索引中的第一个索引字段(最左边)被包含其中时，才可以获得最高效率。
2. GiST类型的复合索引：
在GiST类型的复合索引中，只有当第一个索引字段被包含在查询条件中时，才能决定该查询会扫描多少索引数据，而其他索引字段上的条件只是会限制索引返回的条目。假如第一个索引字段上的大多数数据都有相同的键值，那么此时应用GiST索引就会比较低效。
3. GIN类型的复合索引：
与B-Tree和GiST索引不同的是，GIN复合索引不会受到查询条件中使用了哪些索引字段子集的影响，无论是哪种组合，都会得到相同的效率。
使用复合索引应该谨慎。在大多数情况下，单一字段上的索引就已经足够了，并且还节约时间和空间。除非表的使用模式非常固定，否则超过三个字段的索引几乎没什么用处。
三、组合多个索引：
PostgreSQL可以在查询时组合多个索引(包括同一索引的多次使用)，来处理单个索引扫描不能实现的场合。与此同时，系统还可以在多个索引扫描之间组成AND和OR的条件。比如，一个类似WHERE x = 42 OR x = 47 OR x = 53 OR x = 99的查询，可以被分解成四个独立的基于x字段索引的扫描，每个扫描使用一个查询子句，之后再将这些扫描结果OR在一起并生成最终的结果。另外一个例子是，如果我们在x和y上分别存在独立的索引，那么一个类似WHERE x = 5 AND y = 6的查询，就会分别基于这两个字段的索引进行扫描，之后再将各自扫描的结果进行AND操作并生成最终的结果行。
为了组合多个索引，系统扫描每个需要的索引，然后在内存里组织一个BITMAP，它将给出索引扫描出的数据在数据表中的物理位置。然后，再根据查询的需要，把这些位图进行AND或者OR的操作并得出最终的BITMAP。最后，检索数据表并返回数据行。表的数据行是按照物理顺序进行访问的，因为这是位图的布局，这就意味着任何原来的索引的排序都将消失。如果查询中有ORDER BY子句，那么还将会有一个额外的排序步骤。因为这个原因，以及每个额外的索引扫描都会增加额外的时间，这样规划器有时候就会选择使用简单的索引扫描，即使有多个索引可用也会如此。
四、唯一索引：
CREATE UNIQUE INDEX name ON table (column [, ...]);
五、表达式索引：
表达式索引主要用于在查询条件中存在基于某个字段的函数或表达式的结果与其他值进行比较的情况，如：
SELECT * FROM test1 WHERE lower(col1) = 'value';
此时，如果我们仅仅是在col1字段上建立索引，那么该查询在执行时一定不会使用该索引，而是直接进行全表扫描。如果该表的数据量较大，那么执行该查询也将会需要很长时间。解决该问题的办法非常简单，在test1表上建立基于col1字段的表达式索引，如：
CREATE INDEX test1_lower_col1_idx ON test1 (lower(col1));
SELECT * FROM people WHERE (first_name || ' ' || last_name) = 'John Smith';
和上面的例子一样，尽管我们可能会为first_name和last_name分别创建独立索引，或者是基于这两个字段的复合索引，在执行该查询语句时，这些索引均不会被使用，该查询能够使用的索引只有我们下面创建的表达式索引。
CREATE INDEX people_names ON people ((first_name || ' ' || last_name));
CREATE INDEX命令的语法通常要求在索引表达式周围书写圆括弧，就像我们在第二个例子里显示的那样。如果表达式只是一个函数调用，那么可以省略，就像我们在第一个例子里显示的那样。
从索引维护的角度来看，索引表达式要相对低效一些，因为在插入数据或者更新数据的时候，都必须为该行计算表达式的结果，并将该结果直接存储到索引里。然而在查询时，PostgreSQL就会把它们看做WHERE idxcol = 'constant'，因此搜索的速度等效于基于简单索引的查询。通常而言，我们只是应该在检索速度比插入和更新速度更重要的场景下使用表达式索引。
六、部分索引：
部分索引(partial index)是建立在一个表的子集上的索引，而该子集是由一个条件表达式定义的(叫做部分索引的谓词)。该索引只包含表中那些满足这个谓词的行。
由于不是在所有的情况下都需要更新索引，因此部分索引会提高数据插入和数据更新的效率。然而又因为部分索引比普通索引要小，因此可以更好的提高确实需要索引部分的查询效率。见以下三个示例：
1. 索引字段和谓词条件字段一致：
CREATE INDEX access_log_client_ip_ix ON access_log(client_ip)
WHERE NOT (client_ip inet '192.168.100.0' AND client_ip inet '192.168.100.255');
下面的查询将会用到该部分索引：
SELECT * FROM access_log WHERE url = '/index.html' AND client_ip = inet '212.78.10.32';
下面的查询将不会用该部分索引：
一个不能使用这个索引的查询可以是
SELECT * FROM access_log WHERE client_ip = inet '192.168.100.23';
2. 索引字段和谓词条件字段不一致：
PostgreSQL支持带任意谓词的部分索引，唯一的约束是谓词的字段也要来自于同样的数据表。注意，如果你希望你的查询语句能够用到部分索引，那么就要求该查询语句的条件部分必须和部分索引的谓词完全匹配。 准确说，只有在PostgreSQL能够识别出该查询的WHERE条件在数学上涵盖了该索引的谓词时，这个部分索引才能被用于该查询。
CREATE INDEX orders_unbilled_index ON orders(order_nr) WHERE billed is not true;
下面的查询一定会用到该部分索引：
SELECT * FROM orders WHERE billed is not true AND order_nr 10000;
那么对于如下查询呢？
SELECT * FROM orders WHERE billed is not true AND amount 5000.00;
这个查询将不像上面那个查询这么高效，毕竟查询的条件语句中没有用到索引字段，然而查询条件"billed is not true"却和部分索引的谓词完全匹配，因此PostgreSQL将扫描整个索引。这样只有在索引数据相对较少的情况下，该查询才能更有效一些。
下面的查询将不会用到部分索引。
SELECT * FROM orders WHERE order_nr = 3501;
3. 数据表子集的唯一性约束：
CREATE TABLE tests (
subject text,
target text,
success boolean,
...
);
CREATE UNIQUE INDEX tests_success_constraint ON tests(subject, target) WHERE success;
该部分索引将只会对success字段值为true的数据进行唯一性约束。在实际的应用中，如果成功的数据较少，而不成功的数据较多时，该实现方法将会非常高效。
七、检查索引的使用：
见以下四条建议：
1. 总是先运行ANALYZE。
该命令将会收集表中数值分布状况的统计。在估算一个查询返回的行数时需要这个信息，而规划器则需要这个行数以便给每个可能的查询规划赋予真实的开销值。如果缺乏任何真实的统计信息，那么就会使用一些缺省数值，这样肯定是不准确的。因此，如果还没有运行ANALYZE就检查一个索引的使用状况，那将会是一次失败的检查。
2. 使用真实的数据做实验。
用测试数据填充数据表，那么该表的索引将只会基于测试数据来评估该如何使用索引，而不是对所有的数据都如此使用。比如从100000行中选1000行，规划器可能会考虑使用索引，那么如果从100行中选1行就很难说也会使用索引了。因为100行的数据很可能是存储在一个磁盘页面中，然而没有任何查询规划能比通过顺序访问一个磁盘页面更加高效了。与此同时，在模拟测试数据时也要注意，如果这些数据是非常相似的数据、完全随机的数据，或按照排序顺序插入的数据，都会令统计信息偏离实际数据应该具有的特征。
3. 如果索引没有得到使用，那么在测试中强制它的使用也许会有些价值。有一些运行时参数可以关闭各种各样的查询规划。
4. 强制使用索引用法将会导致两种可能：一是系统选择是正确的，使用索引实际上并不合适，二是查询计划的开销计算并不能反映现实情况。这样你就应该对使用和不使用索引的查询进行计时，这个时候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节点通常表示添加索引的必要性，读取速度可能要快得多。
翻译并编辑，原文出处：
本节简单介绍了XLOG全局(所有进程之间)共享的数据结构:XLogCtlData和XLogCtlInsert。在这两个结构体中,存储了REDO point/Lock等相关重要的信息.
XLogCtlInsert
WAL插入记录时使用的共享数据结构
XLogCtl
XLOG的所有共享内存状态信息
跟踪任意一个后台进程,打印全局变量XLogCtl.
其中:
1.XLogCtl-Insert是XLogCtlInsert结构体变量.
2.RedoRecPtr为5510830896 - 1/48789B30,该值与pg_control文件中的REDO location相对应.
3.ThisTimeLineIDPrevTimeLineID,时间线ID,值为1.
其他相关信息可对照结构体定义阅读.
PostgreSQL 源码解读（4）- 插入数据#3（heap_insert）
PG Source Code