Re: ShmemAlloc errors

Поиск
Список
Период
Сортировка
От Greg Stark
Тема Re: ShmemAlloc errors
Дата
Msg-id 87d6cv1v56.fsf@stark.dyndns.tv
обсуждение исходный текст
Ответ на Re: ShmemAlloc errors  (Nick Burrett <nick@dsvr.net>)
Ответы Re: ShmemAlloc errors
Список pgsql-general
Nick Burrett <nick@dsvr.net> writes:

> At the start of the fourth month, the data from the first month is deleted and
> the database vacummed.

When dropping a quarter of the records of a large table you would need a very
large setting free space map. For an occasional periodic job like this you can
just use VACUUM FULL to rebuild the table and free up the space.

> CREATE TABLE fiveminute ( server CHAR(32),

You know CHAR() is space padded, right?

> CREATE UNIQUE INDEX fiveminute_idx ON fiveminute(server,stamp);
>
> It probably would have made sense to just have an index on the server column,
> but I can't remember why (decision was made Nov-2000).  I suspect that is the
> cause of the index bloat.

Well, having a unique index is good conceptually because it prevents duplicate
insertions from application errors. But it's probably not worth the
performance hit, given that there are a lot more errors it won't catch.

> The database never survived operational use.  The original import of data took
> so long (2+ days) that the re-design was done almost immediately.

How were you importing? The fastest way would be to generate an ascii file in
the format \copy expects.

--
greg

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

Предыдущее
От: "Stephen"
Дата:
Сообщение: Re: VACUUM degrades performance significantly. Database becomes unusable!
Следующее
От: J Smith
Дата:
Сообщение: Using subselects in INSERTs?