>> I've seen cases where it seems the
>> planer doesn't think it'll be getting a unique value or a small set of
>> values even though stats indicates that it should be.
A test case exhibiting the problem would be helpful.
regards, tom lane
---(end
Jim,
> Is there still a good reason to have the histogram stats so low? Should
> the default be changed to more like 100 at this point?
Low overhead. This is actually a TODO for me for 8.1. I need to find some
test cases to set a differential level of histogram access for indexed
fields, so
On Wed, Nov 17, 2004 at 10:32:48PM +, Simon Riggs wrote:
> The main issue is that PostgreSQL's default histogram statistics setting
> is lower than other RDBMS. This means that it is less able to
> discriminate between cases such as yours that are close to the edge.
> This is a trade-off betwee
On Thu, 2004-11-18 at 02:08, David Brown wrote:
> Statistics were run on each table before query execution. The random page
> cost was lowered to 2, but as you can see, the estimated costs are wild
> anyway.
>
> As a comparison, MS SQL Server took less than 15 seconds, or 4 times faster.
>
> My
Hello,
Have you tried increasing the statistics target for orderdate and
rerunning analyze?
Sincerely,
Joshua D. Drake
David Brown wrote:
I'm doing some performance profiling with a simple two-table query:
SELECT L."ProductID", sum(L."Amount")
FROM "drinv" H
JOIN "drinvln" L ON L."OrderNo" = H."O
Dan,
> I'm doing some performance profiling with a simple two-table query:
Please send EXPLAIN ANALYZE for each query, and not just EXPLAIN. Thanks!
--
Josh Berkus
Aglio Database Solutions
San Francisco
---(end of broadcast)---
TIP 6: Have you
I'm doing some performance profiling with a simple two-table query:
SELECT L."ProductID", sum(L."Amount")
FROM "drinv" H
JOIN "drinvln" L ON L."OrderNo" = H."OrderNo"
WHERE
("OrderDate" between '2003-01-01' AND '2003-04-30')
GROUP BY L."ProductID"
drinv and drinvln have about 100,000 and 3,500,00
