Re: [SQL] Yet Another (Simple) Case of Index not used
От | Andreas Pflug |
---|---|
Тема | Re: [SQL] Yet Another (Simple) Case of Index not used |
Дата | |
Msg-id | 3EA27179.6010307@web.de обсуждение исходный текст |
Ответ на | Re: [SQL] Yet Another (Simple) Case of Index not used (Kevin Brown <kevin@sysexperts.com>) |
Ответы |
Re: [SQL] Yet Another (Simple) Case of Index not used
|
Список | pgsql-performance |
Kevin Brown wrote: > >No, but an MVCC-managed counter would be useful in such a system, >wouldn't it? Or am I missing something there, too (the deltas >themselves would be managed as described, and would be applied as >described)? > >So: how much contention would there be if the counter were managed in >exactly the same way as any row of a table is managed? Because I'm >not terribly familiar with how PG manages MVCC (pointers to >documentation on it welcomed) I can't answer that question myself. > > > It looks to me that a "row number -1" really would solve this problem. I think a row counter on each table would be even useful for some kind of auto-vacuum mechanism, that could be triggered if pg_class.reltuples deviates too far from the real row count. Observing this mailing list, missing or outdated statistics still seem to be a major source of performance degradation. We all know these 1000 row estimates from EXPLAIN, don't we? A default vacuum strategy for pgsql newbies should solve a lot of those problems, preventing a lot of "pgsql is slow" threads. Regards, Andreas
В списке pgsql-performance по дате отправления: