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 -- Sent via pgsql-performance mailing list (pgsql-performance@xxxxxxxxxxxxxx) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-performance
