假設我們有一個如下的表：
CREATE TABLE test1 (
id integer,
content varchar
);而應用發出很多以下形式的查詢：
SELECT content FROM test1 WHERE id = constant;在沒有事前準備的情況下，系統不得不掃描整個test1表，一行一行地去找到所有匹配的項。如果test1中有很多行但是只有一小部分行（可能是0或者1）需要被該查詢返回，這顯然是一種低效的方式。但是如果系統被指示維護一個在id列上的索引，它就能使用一種更有效方式來定位匹配行。例如，它可能僅僅需要遍曆一棵搜尋樹的幾層而已。
類似的方法也被用於大部分非小說書籍中：經常被讀者尋找的術語和概念被收集在一個字母序索引中，放在書籍的末尾。感興趣的讀者可以相對快速地掃描索引並跳到合適的頁，而不需要閱讀整本書來尋找感興趣的材料。正如作者的任務是準備好讀者可能會尋找的術語一樣，資料庫程式員也需要預見哪些索引會有用。
正如前面討論的，下列命令可以用來在id列上建立一個索引：
CREATE INDEX test1_id_index ON test1 (id);索引的名字test1_id_index可以自由選擇，但我們最好選擇一個能讓我們想起該索引用途的名字。
為了移除一個索引，可以使用DROP INDEX命令。索引可以隨時被建立或刪除。
一旦一個索引被建立，就不再需要進一步的幹預：系統會在表更新時更新索引，而且會在它覺得使用索引比順序掃描表效率更高時使用索引。但我們可能需要定期地運行ANALYZE命令來更新統計資料以便查詢規劃器能做出正確的決定。通過效能提示的資訊可以瞭解如何找出一個索引是否被使用以及規劃器在何時以及為什麼會選擇不使用索引。索引也會使帶有搜尋條件的UPDATE和DELETE命令受益。
此外索引還可以在串連搜尋中使用。因此，一個定義在串連條件列上的索引可以顯著地提高串連查詢的速度。
在一個大表上建立一個索引會耗費很長的時間。預設情況下，本資料庫允許在索引建立時並行地進行讀（SELECT命令），但寫（INSERT、UPDATE和DELETE）則會被阻塞直到索引建立完成。在生產環境中這通常是不可接受的。
一個索引被建立後，系統必須保持它與表同步。這增加了資料操作的負擔。因此，很少或從不在查詢中使用的索引應該被移除。