Re: strange estimate for number of rows

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
<andrew@libertyrms.info>                              M2P 2A8
                                         +1 416 646 3304 x110