Re: VACUUM and ANALYZE Follow-Up

Поиск
Список
Период
Сортировка
От Mark Dexter
Тема Re: VACUUM and ANALYZE Follow-Up
Дата
Msg-id 5E8F9F5B63726C48836757FE673B584E01215AA4@dcimail.dexterchaney.local
обсуждение исходный текст
Ответ на VACUUM and ANALYZE Follow-Up  ("Mark Dexter" <MDEXTER@dexterchaney.com>)
Ответы Re: VACUUM and ANALYZE Follow-Up  (Tom Lane <tgl@sss.pgh.pa.us>)
Список pgsql-general

Tom, I did read through the links you provided.  Unfortunately, I don't feel qualified to judge the technical merits of the possible solutions.  Since you appear to be well informed on this issue, can I ask you a couple of quick questions?

1. Would it be difficult to add an option to ANALYZE to force it to pretend that there are a minimum number of rows (e.g., ANALYZE MINIMUM 1000 or something)?  This would appear to be a simple-minded way to solve the problem without any concerns about backward compatibility.

2. Why does a newly CREATE'd table behave differently than an empty table after ANALYZE?  Does it make sense that it should?  In the CREATE case, the assumptions appear to be much more reasonable for a table that is going to grow. 

3. Has anyone ever tested whether there is a measurable performance gained after doing ANALYZE on empty or nearly empty tables?  We know that there is a very large (in my case 15x) performance loss when the table starts growing.  If the gain is small or negligable when the tables really are small, then perhaps worrying about maintaining current behaviour is not as important.

The nice thing about option (1) is that is solves the slow insert issue both for empty tables and for tables with a few rows.  It also causes absolutely no backward-compatibility issues.

Thanks very much for your comments on this.  Mark

В списке pgsql-general по дате отправления:

Предыдущее
От: Karsten Hilbert
Дата:
Сообщение: Re: starting the database server
Следующее
От: "Net Virtual Mailing Lists"
Дата:
Сообщение: Re: [ANNOUNCE] USENET vs Mailing Lists Poll ...