postgreSQL命令的詞法分析和語法分析是由Unix工具Yacc和Lex制作的。使用的是 Bison 和
在曲水等地區(qū)，都構(gòu)建了全面的區(qū)域性戰(zhàn)略布局，加強發(fā)展的系統(tǒng)性、市場前瞻性、產(chǎn)品創(chuàng)新能力，以專注、極致的服務(wù)理念，為客戶提供網(wǎng)站設(shè)計制作、網(wǎng)站設(shè)計 網(wǎng)站設(shè)計制作按需求定制網(wǎng)站,公司網(wǎng)站建設(shè),企業(yè)網(wǎng)站建設(shè),品牌網(wǎng)站建設(shè),成都全網(wǎng)營銷推廣,成都外貿(mào)網(wǎng)站建設(shè),曲水網(wǎng)站建設(shè)費用合理。
Flex。
詞法分析和語法分析依賴的文件定義在src\backend\parser下的scan.l和gram.y。其中：
在raw_parser函數(shù)(在src/backend/parser/parser.c下)中，主要通過調(diào)用Lex和Yacc配合生成的base_yyparse函數(shù)來實現(xiàn)詞法分析和語法分析的工作。
其他的重要源碼文件：
輔助腳本：
SQL關(guān)鍵字定義及查找函數(shù)
SQL關(guān)鍵字列表
因為查找是采用二分查找法。如果添加關(guān)鍵字，需要保持name的順序。
本文主要介紹PG在執(zhí)行查詢時，對SQL的語義分析重寫過程中的查詢對象解析過程，處理的函數(shù)為addRangeTableEntry，分析查詢對象信息。
本函數(shù)是解析查詢 (包含增刪改查操作) 執(zhí)行過程中涉及的查詢對象 (表、視圖、子查詢等) 的信息。
每次調(diào)用只解析一個對象。
1、通過觀察addRangeTableEntry的執(zhí)行過程，了解SQL語義解析transformFromClause的處理過程。
2、表結(jié)構(gòu)信是從緩存中結(jié)構(gòu)讀取，然后獲取自己需要的信息。
3、語義分析后轉(zhuǎn)換為relid（關(guān)聯(lián)對象id），提升查詢執(zhí)行的處理效率。
一、索引的類型：
PostgreSQL提供了多種索引類型：B-Tree、Hash、GiST和GIN，由于它們使用了不同的算法，因此每種索引類型都有其適合的查詢類型，缺省時，CREATE INDEX命令將創(chuàng)建B-Tree索引。
1. B-Tree:
CREATE TABLE test1 (
id integer,
content varchar
);
CREATE INDEX test1_id_index ON test1 (id);
B-Tree索引主要用于等于和范圍查詢，特別是當索引列包含操作符" 、=和"作為查詢條件時，PostgreSQL的查詢規(guī)劃器都會考慮使用B-Tree索引。在使用BETWEEN、IN、IS NULL和IS NOT NULL的查詢中，PostgreSQL也可以使用B-Tree索引。然而對于基于模式匹配操作符的查詢，如LIKE、ILIKE、~和 ~*，僅當模式存在一個常量，且該常量位于模式字符串的開頭時，如col LIKE 'foo%'或col ~ '^foo'，索引才會生效，否則將會執(zhí)行全表掃描，如：col LIKE '%bar'。
2. Hash：
CREATE INDEX name ON table USING hash (column);
散列(Hash)索引只能處理簡單的等于比較。當索引列使用等于操作符進行比較時，查詢規(guī)劃器會考慮使用散列索引。
這里需要額外說明的是，PostgreSQL散列索引的性能不比B-Tree索引強，但是散列索引的尺寸和構(gòu)造時間則更差。另外，由于散列索引操作目前沒有記錄WAL日志，因此一旦發(fā)生了數(shù)據(jù)庫崩潰，我們將不得不用REINDEX重建散列索引。
3. GiST：
GiST索引不是一種單獨的索引類型，而是一種架構(gòu)，可以在該架構(gòu)上實現(xiàn)很多不同的索引策略。從而可以使GiST索引根據(jù)不同的索引策略，而使用特定的操作符類型。
4. GIN：
GIN索引是反轉(zhuǎn)索引，它可以處理包含多個鍵的值(比如數(shù)組)。與GiST類似，GIN同樣支持用戶定義的索引策略，從而可以使GIN索引根據(jù)不同的索引策略，而使用特定的操作符類型。作為示例，PostgreSQL的標準發(fā)布中包含了用于一維數(shù)組的GIN操作符類型，如：、=、等。
二、復合索引：
PostgreSQL中的索引可以定義在數(shù)據(jù)表的多個字段上，如：
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類型的復合索引中，只有當?shù)谝粋€索引字段被包含在查詢條件中時，才能決定該查詢會掃描多少索引數(shù)據(jù)，而其他索引字段上的條件只是會限制索引返回的條目。假如第一個索引字段上的大多數(shù)數(shù)據(jù)都有相同的鍵值，那么此時應(yīng)用GiST索引就會比較低效。
3. GIN類型的復合索引：
與B-Tree和GiST索引不同的是，GIN復合索引不會受到查詢條件中使用了哪些索引字段子集的影響，無論是哪種組合，都會得到相同的效率。
使用復合索引應(yīng)該謹慎。在大多數(shù)情況下，單一字段上的索引就已經(jīng)足夠了，并且還節(jié)約時間和空間。除非表的使用模式非常固定，否則超過三個字段的索引幾乎沒什么用處。
三、組合多個索引：
PostgreSQL可以在查詢時組合多個索引(包括同一索引的多次使用)，來處理單個索引掃描不能實現(xiàn)的場合。與此同時，系統(tǒng)還可以在多個索引掃描之間組成AND和OR的條件。比如，一個類似WHERE x = 42 OR x = 47 OR x = 53 OR x = 99的查詢，可以被分解成四個獨立的基于x字段索引的掃描，每個掃描使用一個查詢子句，之后再將這些掃描結(jié)果OR在一起并生成最終的結(jié)果。另外一個例子是，如果我們在x和y上分別存在獨立的索引，那么一個類似WHERE x = 5 AND y = 6的查詢，就會分別基于這兩個字段的索引進行掃描，之后再將各自掃描的結(jié)果進行AND操作并生成最終的結(jié)果行。
為了組合多個索引，系統(tǒng)掃描每個需要的索引，然后在內(nèi)存里組織一個BITMAP，它將給出索引掃描出的數(shù)據(jù)在數(shù)據(jù)表中的物理位置。然后，再根據(jù)查詢的需要，把這些位圖進行AND或者OR的操作并得出最終的BITMAP。最后，檢索數(shù)據(jù)表并返回數(shù)據(jù)行。表的數(shù)據(jù)行是按照物理順序進行訪問的，因為這是位圖的布局，這就意味著任何原來的索引的排序都將消失。如果查詢中有ORDER BY子句，那么還將會有一個額外的排序步驟。因為這個原因，以及每個額外的索引掃描都會增加額外的時間，這樣規(guī)劃器有時候就會選擇使用簡單的索引掃描，即使有多個索引可用也會如此。
四、唯一索引：
CREATE UNIQUE INDEX name ON table (column [, ...]);
五、表達式索引：
表達式索引主要用于在查詢條件中存在基于某個字段的函數(shù)或表達式的結(jié)果與其他值進行比較的情況，如：
SELECT * FROM test1 WHERE lower(col1) = 'value';
此時，如果我們僅僅是在col1字段上建立索引，那么該查詢在執(zhí)行時一定不會使用該索引，而是直接進行全表掃描。如果該表的數(shù)據(jù)量較大，那么執(zhí)行該查詢也將會需要很長時間。解決該問題的辦法非常簡單，在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分別創(chuàng)建獨立索引，或者是基于這兩個字段的復合索引，在執(zhí)行該查詢語句時，這些索引均不會被使用，該查詢能夠使用的索引只有我們下面創(chuàng)建的表達式索引。
CREATE INDEX people_names ON people ((first_name || ' ' || last_name));
CREATE INDEX命令的語法通常要求在索引表達式周圍書寫圓括弧，就像我們在第二個例子里顯示的那樣。如果表達式只是一個函數(shù)調(diào)用，那么可以省略，就像我們在第一個例子里顯示的那樣。
從索引維護的角度來看，索引表達式要相對低效一些，因為在插入數(shù)據(jù)或者更新數(shù)據(jù)的時候，都必須為該行計算表達式的結(jié)果，并將該結(jié)果直接存儲到索引里。然而在查詢時，PostgreSQL就會把它們看做WHERE idxcol = 'constant'，因此搜索的速度等效于基于簡單索引的查詢。通常而言，我們只是應(yīng)該在檢索速度比插入和更新速度更重要的場景下使用表達式索引。
六、部分索引：
部分索引(partial index)是建立在一個表的子集上的索引，而該子集是由一個條件表達式定義的(叫做部分索引的謂詞)。該索引只包含表中那些滿足這個謂詞的行。
由于不是在所有的情況下都需要更新索引，因此部分索引會提高數(shù)據(jù)插入和數(shù)據(jù)更新的效率。然而又因為部分索引比普通索引要小，因此可以更好的提高確實需要索引部分的查詢效率。見以下三個示例：
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支持帶任意謂詞的部分索引，唯一的約束是謂詞的字段也要來自于同樣的數(shù)據(jù)表。注意，如果你希望你的查詢語句能夠用到部分索引，那么就要求該查詢語句的條件部分必須和部分索引的謂詞完全匹配。 準確說，只有在PostgreSQL能夠識別出該查詢的WHERE條件在數(shù)學上涵蓋了該索引的謂詞時，這個部分索引才能被用于該查詢。
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將掃描整個索引。這樣只有在索引數(shù)據(jù)相對較少的情況下，該查詢才能更有效一些。
下面的查詢將不會用到部分索引。
SELECT * FROM orders WHERE order_nr = 3501;
3. 數(shù)據(jù)表子集的唯一性約束：
CREATE TABLE tests (
subject text,
target text,
success boolean,
...
);
CREATE UNIQUE INDEX tests_success_constraint ON tests(subject, target) WHERE success;
該部分索引將只會對success字段值為true的數(shù)據(jù)進行唯一性約束。在實際的應(yīng)用中，如果成功的數(shù)據(jù)較少，而不成功的數(shù)據(jù)較多時，該實現(xiàn)方法將會非常高效。
七、檢查索引的使用：
見以下四條建議：
1. 總是先運行ANALYZE。
該命令將會收集表中數(shù)值分布狀況的統(tǒng)計。在估算一個查詢返回的行數(shù)時需要這個信息，而規(guī)劃器則需要這個行數(shù)以便給每個可能的查詢規(guī)劃賦予真實的開銷值。如果缺乏任何真實的統(tǒng)計信息，那么就會使用一些缺省數(shù)值，這樣肯定是不準確的。因此，如果還沒有運行ANALYZE就檢查一個索引的使用狀況，那將會是一次失敗的檢查。
2. 使用真實的數(shù)據(jù)做實驗。
用測試數(shù)據(jù)填充數(shù)據(jù)表，那么該表的索引將只會基于測試數(shù)據(jù)來評估該如何使用索引，而不是對所有的數(shù)據(jù)都如此使用。比如從100000行中選1000行，規(guī)劃器可能會考慮使用索引，那么如果從100行中選1行就很難說也會使用索引了。因為100行的數(shù)據(jù)很可能是存儲在一個磁盤頁面中，然而沒有任何查詢規(guī)劃能比通過順序訪問一個磁盤頁面更加高效了。與此同時，在模擬測試數(shù)據(jù)時也要注意，如果這些數(shù)據(jù)是非常相似的數(shù)據(jù)、完全隨機的數(shù)據(jù)，或按照排序順序插入的數(shù)據(jù)，都會令統(tǒng)計信息偏離實際數(shù)據(jù)應(yīng)該具有的特征。
3. 如果索引沒有得到使用，那么在測試中強制它的使用也許會有些價值。有一些運行時參數(shù)可以關(guān)閉各種各樣的查詢規(guī)劃。
4. 強制使用索引用法將會導致兩種可能：一是系統(tǒng)選擇是正確的，使用索引實際上并不合適，二是查詢計劃的開銷計算并不能反映現(xiàn)實情況。這樣你就應(yīng)該對使用和不使用索引的查詢進行計時，這個時候EXPLAIN ANALYZE命令就很有用了。
1. 啟動數(shù)據(jù)庫服務(wù)器(posgres用戶)：
[postgres@localhost bin]$ postgres -D /opt/postgresql/data/ /opt/postgresql/log/pg_server.log 21
[1] 4508
當然如果設(shè)置了環(huán)境變量
PGDATA=/opt/postgresql/data
export PGDATA
后，可使用pg_ctl工具進行啟動:
[postgres@localhost log]$ pg_ctl start -l /opt/postgresql/log/pg_server.log
pg_ctl: another server might be running; trying to start server anyway
pg_ctl: could not start server
Examine the log output.
[postgres@localhost log]$
因為之前已經(jīng)啟動，所以打印“another server might be running”。此時，查看日志，有如下信息:
[postgres@localhost log]$ cat pg_server.log
FATAL: lock file "postmaster.pid" already exists
HINT: Is another postmaster (PID 4491) running in data directory "/opt/postgresql/data"?
[postgres@localhost log]$
當然，最簡的.啟動方式是：
[postgres@localhost ~]$ pg_ctl start
server starting
[postgres@localhost ~]$ LOG: database system was shut down at 2011-07-09 13:58:00 CST
LOG: autovacuum launcher started
LOG: database system is ready to accept connections
如果要在操作系統(tǒng)啟動時就啟動PG,可以在/etc/rc.d/rc.local 文件中加以下語句：
/opt/postgresql/bin/pg_ctl start -l /opt/postgresql/log/pg_server.log -D /opt/postgresql/data
2.關(guān)閉服務(wù)器
最簡單方法：
[postgres@localhost ~]$ pg_ctl stop
waiting for server to shut down.... done
server stopped
與Oracle相同，在關(guān)閉時也可采用不同的模式，簡介如下：
SIGTERM
不再允許新的連接，但是允許所有活躍的會話正常完成他們的工作，只有在所有會話都結(jié)束任務(wù)后才關(guān)閉。這是智能關(guān)閉。
SIGINT
不再允許新的連接，向所有活躍服務(wù)器發(fā)送 SIGTERM(讓它們立刻退出)，然后等待所有子進程退出并關(guān)閉數(shù)據(jù)庫。這是快速關(guān)閉。
SIGQUIT
令 postgres 向所有子進程發(fā)送 SIGQUIT 并且立即退出(所有子進程也會立即退出)，而不會妥善地關(guān)閉數(shù)據(jù)庫系統(tǒng)。這是立即關(guān)閉。這樣做會導致下次啟動時的恢復(通過重放 WAL 日志)。我們推薦只在緊急的時候使用這個方法。
SIGKILL
此選項盡量不要使用，這樣會阻止服務(wù)器清理共享內(nèi)存和信號燈資源，那樣的話你只能在啟動服務(wù)器之前自己手工做這件事。另外，SIGKILL 直接把 postgres 殺掉，而不會等它把信號中繼給它的子進程，因此我們還需要手工殺掉每個獨立子進程。
使用方法舉例：
[postgres@localhost ~]$ pg_ctl stop -o SIGTERM
LOG: received smart shutdown request
LOG: autovacuum launcher shutting down
waiting for server to shut down....LOG: shutting down
LOG: database system is shut down
done
server stopped
[postgres@localhost ~]$
最快速關(guān)閉方法：kill postgres 進程
[postgres@localhost ~]$ kill -INT `head -1 /opt/postgresql/data/postmaster.pid`
[postgres@localhost ~]$ LOG: received fast shutdown request
LOG: aborting any active transactions
LOG: autovacuum launcher shutting down
LOG: shutting down
LOG: database system is shut down
附：postgre啟動后的進程，如下:
[postgres@localhost ~]$ ps -ef|grep post
root 4609 4543 0 13:57 pts/2 00:00:00 su - postgres
postgres 4610 4609 0 13:57 pts/2 00:00:00 -bash
postgres 4724 1 0 14:08 pts/2 00:00:00 /opt/postgresql/bin/postgres
postgres 4726 4724 0 14:08 ? 00:00:00 postgres: writer process
postgres 4727 4724 0 14:08 ? 00:00:00 postgres: wal writer process
postgres 4728 4724 0 14:08 ? 00:00:00 postgres: autovacuum launcher process
postgres 4729 4724 0 14:08 ? 00:00:00 postgres: stats collector process
postgres 4752 4610 0 14:11 pts/2 00:00:00 ps -ef
postgres 4753 4610 0 14:11 pts/2 00:00:00 grep post
[postgres@localhost ~]$
重慶分公司
重慶分公司
