greenplum 外表在修改master，pg_exttable的數(shù)據(jù)字典。segment中不受影響

我創(chuàng)建一張外表
CREATE EXTERNAL TABLE yyw_ext(name )LOCATION ('gpfdist://10.199.111.239:8081/yyw_ext.txt')FORMAT 'text' (delimiter 't' null '\N' escape '\')
那么他會在gp的master節(jié)點和segment節(jié)點上pg_exttable字典表中都加一條記錄表示外表文件的路徑。
其中l(wèi)ocation字段是記錄url的比如 "{gpfdist://10.199.111.239:8081/yyw_ext.txt}"
剛建立的時候。master和segment字典表都是一致的。
現(xiàn)在我人為的修改master節(jié)點的pg_exttable表。修改location字段使他指向新的地址 ,但是segment的地址不變。
我測試發(fā)現(xiàn)。外表的連接地址確實是修改之后的也確實是新的數(shù)據(jù)。但是現(xiàn)在segment和master的pg_exttable中的值不一致了
不知道會不會有隱藏的坑。然后雖然gpfdist協(xié)議是segment并行讀取外表文件。但是從測試上來看好像就是用到了master的數(shù)據(jù)字典
沒有用到segment的數(shù)據(jù)字典。那這個segment上的pg_exttable表有什么作用呢。我表示奇怪。

回答

編輯回答

背叛者

首先，我不知道為什么你需要人為地修改master節(jié)點的pg_exttable表從而導(dǎo)致master節(jié)點和segment節(jié)點的數(shù)據(jù)字典不一致。如果你只是想讓external table指向新的位置，你完成可以drop掉舊的external table，然后創(chuàng)建一個名字一樣的新的external table，但指向新的位置。

其次，從實現(xiàn)代碼看，如你測試的結(jié)果所示，gpfdist協(xié)議的外部表執(zhí)行的時候使用的是master節(jié)點的數(shù)據(jù)字典，location的信息通過查詢計劃分發(fā)到segment節(jié)點。換句話說，在正常的查詢中，gpfdist協(xié)議的外部表沒有用到segment的數(shù)據(jù)字典。但是，Greenplum Database有一種模式叫utility模式。用戶是可以通過utility模式直接連接到segment節(jié)點，然后在segment節(jié)點上面執(zhí)行查詢。在這種情況下，如果需要訪問gpfdist協(xié)議的外部表，那么使用的將是segment的數(shù)據(jù)字典（也就是segment的pg_exttable中的location信息）。因為utility模式下，每個segment就是一個單獨的postgresql數(shù)據(jù)庫，它不會去訪問，也不能去訪問master的數(shù)據(jù)字典。

最后，結(jié)論就是：（1）你不應(yīng)該人為地去修改master節(jié)點的pg_exttable表；（2）正常情況下，對于gpfdist協(xié)議的外部表，即便master和segment的pg_exttable信息不一致，對查詢結(jié)果也不會有任何影響；但在utility模式下，在master上訪問同樣的external table，和在segment上訪問同樣的external table，結(jié)果可能會不一樣。

2017年1月8日 13:49