Re: [HACKERS] Slow count(*) again...

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