Re: Performance problems with large telemetric datasets on 7.4.2

Поиск
Список
Период
Сортировка
От Sven Clement
Тема Re: Performance problems with large telemetric datasets on 7.4.2
Дата
Msg-id 881035ea0708060254w32fa164di32d3579c2b0ebf14@mail.gmail.com
обсуждение исходный текст
Ответ на Re: Performance problems with large telemetric datasets on 7.4.2  (Heikki Linnakangas <heikki@enterprisedb.com>)
Ответы Re: Performance problems with large telemetric datasets on 7.4.2
Список pgsql-performance
Ok thanks everybody for the calrification, after all now I allready learned something new... ;)

My employer is currently thinking about migration to 8.2.x because of your feedback, so I think that the problem could be resolved... ;)

Thanks to everyone...

Sven Clement

2007/8/6, Heikki Linnakangas <heikki@enterprisedb.com>:
Sven Clement wrote:
> Partially I found that one in the PostgreSQL Documentation for the
> 7.x.xversions under the command REINDEX where they claim that you
> should run a
> reindex under certain circumstances and for my comprehension this says that
> with some access pattern (as ours (major writes / one big delete per day))
> the index may be corrupted or otherwise not really useful.

Up to 7.3, periodical REINDEX was needed to trim down bloated indexes.
Since 7.4, empty index pages are recycled so that's no longer necessary.
You can still end up with larger than necessary indexes in recent
versions under unusual access patterns, like if you delete all but a few
index tuples from each index page, but it's rare in practice. And it's
not unbounded growth like in <= 7.3.

In any case, the indexes won't become corrupt.

--
  Heikki Linnakangas
  EnterpriseDB   http://www.enterprisedb.com



--
DSIGN.LU
Sven Clement
+352 621 63 21 18
sven@dsign.lu

www.dsign.lu

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

Предыдущее
От: Heikki Linnakangas
Дата:
Сообщение: Re: Performance problems with large telemetric datasets on 7.4.2
Следующее
От: Henrik Zagerholm
Дата:
Сообщение: Planner making wrong decisions 8.2.4. Insane cost calculations.