Andrew Sullivan [EMAIL PROTECTED] writes:
The statistics on transaction_date and product_id are set to 1000.
Everything is all analysed nicely. But I'm getting a poor plan,
because of an estimate that the number of rows to be returned is
about double how many actually are:
explain analyse
Daniel Manley [EMAIL PROTECTED] writes:
The product_id alone gives a difference of a millions rows from estimate
to actual, vs. the factor of 2 from the transaction_date.
You should be thinking in terms of ratios, not absolute difference.
The rows estimate for product_id doesn't look too bad
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
On Thu, Nov 13, 2003 at 04:37:03PM -0500, Andrew Sullivan wrote:
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.
I
