On 04/02/11 10:01, Mladen Gogala wrote:
> In the meantime, the fire is burning. What should the hapless owner of
> the database application do in the meantime? Tell the users that it
> will be better in the next version? As I've said before: hints are
> make it or break it point. Without hints, I cannot consider Postgres
> for the mission critical projects. I am managing big databases for
> living and I flatter myself that after more than two decades of doing
> it, I am not too bad at it.
This is somewhat of a straw man argument. This sort of query that the
optimizer does badly usually gets noticed during the test cycle i.e
before production, so there is some lead time to get a fix into the
code, or add/subtract indexes/redesign the query concerned.
The cases I've seen in production typically involve "outgrowing"
optimizer parameter settings: (e.g work_mem, effective_cache_size) as
the application dataset gets bigger over time. I would note that this is
*more* likely to happen with hints, as they lobotomize the optimizer so
it *cannot* react to dataset size or distribution changes.
regards
Mark
