Re: [HACKERS] Slow count(*) again...
| От | Robert Haas |
|---|---|
| Тема | Re: [HACKERS] Slow count(*) again... |
| Дата | |
| Msg-id | AANLkTim0AbX71fPTOQa++q9PAGn7SL2ziYpRnb_JMyNR@mail.gmail.com обсуждение исходный текст |
| Ответ на | Re: [HACKERS] Slow count(*) again... (Vitalii Tymchyshyn <tivv00@gmail.com>) |
| Ответы |
Re: [HACKERS] Slow count(*) again...
|
| Список | pgsql-performance |
On Thu, Feb 3, 2011 at 4:54 AM, Vitalii Tymchyshyn <tivv00@gmail.com> wrote: > 02.02.11 20:32, Robert Haas написав(ла): >> >> Yeah. Any kind of bulk load into an empty table can be a problem, >> even if it's not temporary. When you load a bunch of data and then >> immediately plan a query against it, autoanalyze hasn't had a chance >> to do its thing yet, so sometimes you get a lousy plan. > > May be introducing something like 'AutoAnalyze' threshold will help? I mean > that any insert/update/delete statement that changes more then x% of table > (and no less then y records) must do analyze right after it was finished. > Defaults like x=50 y=10000 should be quite good as for me. That would actually be a pessimization for many real world cases. Consider: COPY COPY COPY COPY COPY COPY COPY COPY COPY COPY COPY COPY COPY SELECT -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company
В списке pgsql-performance по дате отправления: