Alban Hertroys <[EMAIL PROTECTED]> writes: > tablename | mm_product_table > attname | number > histogram_bounds | {2930,3244,3558,3872,4186,4500,4814,5128,5442,5756,6070}
> tablename | mm_insrel_table > attname | snumber > histogram_bounds | > {135,3768,4780,14822,57048,92958,125442,158954,433002,502836,610034} Hmm ... if I'm not still confused, these are the two columns being mergejoined in your slow query (would you double-check that?). But the numbers don't seem to add up. Given those stats the estimate should be that something over 20% of the mm_insrel_table has to be scanned to complete the join (since 6070 falls into the third decile of the other histogram). But we saw from Alban's original post that the planner must be estimating well under 10% of the table needs to be scanned. Either we're still confused about which columns are being joined, or there's some weird bug in the computation. regards, tom lane ---------------------------(end of broadcast)--------------------------- TIP 5: don't forget to increase your free space map settings