防止PostgreSQL有時(shí)選擇錯(cuò)誤的查詢計(jì)劃對(duì)于使用PostgreSQL 8.4.9進(jìn)行查詢的PostgreSQL性能，我遇到了一個(gè)奇怪的問題。此查詢是在3D卷中選擇一組點(diǎn)，使用LEFT OUTER JOIN若要添加存在關(guān)聯(lián)ID的相關(guān)ID列，請(qǐng)執(zhí)行以下操作。的小變化x范圍會(huì)導(dǎo)致PostgreSQL選擇不同的查詢計(jì)劃，執(zhí)行時(shí)間從0.01秒到50秒不等。這是一個(gè)有問題的查詢：SELECT treenode.id AS id,        treenode.parent_id AS parentid,        (treenode.location).x AS x,        (treenode.location).y AS y,        (treenode.location).z AS z,        treenode.confidence AS confidence,        treenode.user_id AS user_id,        treenode.radius AS radius,        ((treenode.location).z - 50) AS z_diff,        treenode_class_instance.class_instance_id AS skeleton_id  FROM treenode LEFT OUTER JOIN          (treenode_class_instance INNER JOIN           class_instance ON treenode_class_instance.class_instance_id    = class_instance.id                             AND class_instance.class_id = 7828307)        ON (treenode_class_instance.treenode_id = treenode.id                   AND treenode_class_instance.relation_id = 7828321)        WHERE treenode.project_id = 4     AND (treenode.location).x >= 8000     AND (treenode.location).x <= (8000 + 4736)     AND (treenode.location).y >= 22244     AND (treenode.location).y <= (22244 + 3248)     AND (treenode.location).z >= 0     AND (treenode.location).z <= 100   ORDER BY parentid DESC, id, z_diff   LIMIT 400;我不是解析這些查詢計(jì)劃的專家，但明顯的區(qū)別似乎在于x它使用的范圍是Hash Left Join為L(zhǎng)EFT OUTER JOIN(這非?？?，而對(duì)于另一個(gè)范圍，它使用的是Nested Loop Left Join(這似乎很慢)。在這兩種情況下，查詢都返回大約90行。如果我做了SET ENABLE_NESTLOOP TO FALSE在查詢的慢版本之前，它運(yùn)行得非?？欤依斫庖话銇碚f，使用這種設(shè)置是個(gè)壞主意。.例如，我是否可以創(chuàng)建一個(gè)特定的索引，以使查詢計(jì)劃者更有可能選擇明顯更有效的策略？有人能提出為什么PostgreSQL的查詢規(guī)劃器會(huì)為其中一個(gè)查詢選擇這么糟糕的策略嗎？下面我已經(jīng)包含了可能有幫助的模式的細(xì)節(jié)。