Steve wrote: > >Can you find any cases where it makes a worse choice than before? > >Another thing to pay attention to is whether the planning time gets > >noticeably worse. If we can't find any cases where it loses badly > >on those measures, I'll feel comfortable in applying it... > > Okay, here's the vedict; all the "extremely slow" queries (i.e. > queries that took more than 30 seconds and upwards of several minutes to > complete) are now running in the realm of reason. In fact, most queries > that took between 1 and 4 minutes are now down to taking about 9 seconds > which is obviously a tremendous improvement. > > A few of the queries that were taking 9 seconds or less are > "slightly slower" -- meaning a second or two slower. However most of them > are running at the same speed they were before, or better. > > So I'd say as far as I can tell with my application and my > dataset, this change is solid and an obvious improvement.
Maybe it would be interesting to see in detail those cases that got a bit slower, to further tweak the heuristic if necessary. Is the extra time, time spent in planning or in execution? -- Alvaro Herrera http://www.CommandPrompt.com/ PostgreSQL Replication, Consulting, Custom Development, 24x7 support ---------------------------(end of broadcast)--------------------------- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
