> 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.
Talk to you later,
In response to
pgsql-performance by date
|Next:||From: Alvaro Herrera||Date: 2007-04-16 23:01:04|
|Subject: Re: [HACKERS] choose_bitmap_and again (was Re: [PERFORM] Strangely Variable Query Performance)|
|Previous:||From: Ron Mayer||Date: 2007-04-16 18:24:15|
|Subject: Re: Basic Q on superfluous primary keys|
pgsql-hackers by date
|Next:||From: Zoltan Boszormenyi||Date: 2007-04-16 22:39:22|
|Subject: Re: [HACKERS] Re: IDENTITY/GENERATED v36 Re: Final version
of IDENTITY/GENERATED patch|
|Previous:||From: Andrew Dunstan||Date: 2007-04-16 22:07:47|
|Subject: Re: [RFC] PostgreSQL Access Control Extension (PGACE)|
pgsql-patches by date
|Next:||From: Tom Lane||Date: 2007-04-16 22:18:38|
|Subject: Re: scrollable cursor support without MOVE statement |
|Previous:||From: Simon Riggs||Date: 2007-04-16 21:01:14|
|Subject: Re: scrollable cursor support without MOVE statement|