Re: ShmemAlloc errors

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: ShmemAlloc errors
Дата
Msg-id 22440.1066400462@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Re: ShmemAlloc errors  (Nick Burrett <nick@dsvr.net>)
Ответы Re: ShmemAlloc errors
Список pgsql-general
Nick Burrett <nick@dsvr.net> writes:
> Tom Lane wrote:
>> Have you thought about
>> collapsing these into *one* table with an extra key column?  Also, it'd
>> likely be better to combine the date and time into a timestamp column.

> I tried it back in the days when we only had around 1000 tables.
> Problem was that inserts and deletes took a *very* long time.  IIRC a
> one row insert was taking over 10 seconds.  I think this was because the
> index files were growing to several gigabytes.

That really shouldn't happen.  If the date/time range that you are
storing moves over time (ie, you delete old stuff at the same rate you
are adding new stuff) then I can see that you would have had an
index-bloat problem, since the old btree code was unable to recycle
no-longer-needed subtrees.  (This issue should go away in 7.4, FWIW.)
However, that should only affect the size of the index on disk; I can't
see that it would have much of an impact on insert or delete time.
For sure I don't see how an insert could take 10 seconds.  What indexes
and foreign keys do you have on these tables?

It would be worth revisiting this and trying to understand where the
performance problem is, rather than just assuming that you have to work
around it.

            regards, tom lane

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

Предыдущее
От: Nick Burrett
Дата:
Сообщение: Re: ShmemAlloc errors
Следующее
От: Nick Burrett
Дата:
Сообщение: Re: ShmemAlloc errors