Re: [HACKERS] choose_bitmap_and again (was Re: [PERFORM] Strangely Variable Query Performance)

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