在很長一段時間內，PostgreSQL都被認為是MySQL的替代品。但是，在那段時間里，根本沒有辦法使他達到MySQL所能達到的水平。最近幾年里，這些問題都無法解決，并且產生了許多有趣的工具來彌補PG。我們在Disqus中使用了兩個Slony和pgbouncer。Slony讓我們可以復制數據（有時候也可以分區），而pgbouncer為我們解決了保持鏈接和連接池的問題。

另外，讓我們看看他們的語言：我這個星期很高興能夠學會如何在PGSQL8.4中使用遞歸查詢，他們實在太強大了。這就是我這篇文章所真正想要和大家討論的東西。MySQL讓我們可以工作，并且工作的很好，但你只能在引擎的結構內完成。雖然在PG中依然如此，但你有了更多的選擇。因此，我想講講樹的線索化的問題。

大家都知道Disqus不僅僅是最大的Django網站（我們每個月有近100萬的訪問量），同時，他也是他也是一個最大的網上評論系統。我們為上千個網站提供了許多功能，最基本的就是評論作為樹狀結構的線索化。

PostgreSQL提供了許多個關于線索化的解決方案。最常用的（也是最高效的）方法就是改良版的前序遍歷。簡單的說，他增加了一個左序，一個右序，他們會在你添加評論時被更新。我們還有另一個標準的方法（Reddit使用的很歡樂），那就是“取出所有的東西，然后在內存中完成操作”。實際上，不僅僅只有Reddit這樣做。

繼續看看PGSQL為我們提供的東西，我們還可以找到兩個選項（最低在8.4版本）。其中一個是使用PG的內建模塊稱為ltree。他允許你將一個節點的完整路徑（所有父結點）存儲下來，同時允許你通過標準的sql語句查詢他們。當你需要按照“最早發布”排序的時候，它會非常有用，因為這樣以來，就變為了簡單的按照“ltree——column”排序。然而，和大部分時候一樣，Disqus的情況沒有這么簡單。

我們的第二個解決方案就是遞歸查詢。他花了我很長一段時間來理解他是怎么工作的，但是當我理解后，我被他的能力深深的吸引了。Postgre提供了許多MySQL所沒有的特性，比如over()修飾符。他們真的表現的非常好。

讓我們繼續深入我們的問題，這會是一個大問題。現在，Disqus和Reddit處理多線程的方法一樣，都是和網上其他的解決方案一樣，非常的簡陋。我說的是簡陋不是說代碼寫的不好，而是他的優化沒有做到他應該做到的。直到某些人（就是你，Obama同學）開始使用這個程序，并且所有人都想回復他的話，我們才發現出問題了。我們再一次想到了Django（即使他們越來越大）并且通過業務邏輯將他們分組。

自從8.4開始，我們就可以使用遞歸查詢來解決這個問題（在許多情況下我們已經自己開始這么做了，雖然會有點復雜）這個相當的簡單。