On Thu, Nov 13, 2003 at 03:19:08PM -0500, Tom Lane wrote: > because the system can usually do all right on range estimates if you've > let it run an ANALYZE with enough histogram bins. Could we see the > pg_stats row for transaction_date?
Do you want the whole thing? I left out the really verbose bits when I posted this in the original: SELECT attname,null_frac,avg_width,n_distinct,correlation FROM pg_stats where tablename = 'transactions_posted' AND attname in ('transaction_date','product_id'); attname | null_frac | avg_width | n_distinct | correlation ------------------+-----------+-----------+------------+------------- product_id | 0 | 4 | 2 | 0.200956 transaction_date | 0 | 8 | -0.200791 | 0.289248 > > Since you need about a factor of 3 change in the cost estimate to get it to > switch plans, changing random_page_cost by a factor of 2 ain't gonna do > it (the other two numbers are second-order adjustments unlikely to have > much effect, I think). Try 1.5, or even less ... of course, you have to > keep an eye on your other queries and make sure they don't go nuts, but > from what I've heard about your hardware setup a low random_page_cost > isn't out of line with the physical realities. Actually, this one's on an internal box, and I think 1.5 is too low -- it's really just a pair of mirrored SCSI disks on a PCI controller in this case. That does the trick, though, so maybe I'm just being too conservantive. A -- ---- Andrew Sullivan 204-4141 Yonge Street Afilias Canada Toronto, Ontario Canada <[EMAIL PROTECTED]> M2P 2A8 +1 416 646 3304 x110 ---------------------------(end of broadcast)--------------------------- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faqs/FAQ.html