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.
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 verbos
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 ba
Hi, I'm the lead developer on the project this concerns (forgive my
newbiness on this list).
We tried a couple of scenarios with effective_cache_size=6,
cpu_index_tuple_cost=0.0001 and random_page_cost=2 with no change in the
plan.
explain analyse select * from tablename where transaction_
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 an
