Максимальный объем БД на PostgreSQL

Maxim Timofeyev
Дата: 13.02.2004 18:09:42
Какие объемы БД держит PostgreSQL без проблем?
Вот у меня сейчас находится в разработке БД. Кол-во записей в основной таблице -- 3400000.
Объем данных в текстовом формате -- около 1,5Gb.
Объем каталога сервера PostgreSQL на FS -- 2,4Gb (с индексами и логами. ;))

На сервере 512Mb. Диск SATA.

Вопрос встал потому, что как-то сильно тормозит на некоторых операциях. Некоторые, типа select * from table order by... через X минут выкидывают сообщения, что не хватает памяти. (select * я не использую). Пробовал ограничивать LIMIT'ом возвращаемый результат -- эффект тот же.
мдя
Дата: 13.02.2004 18:41:41
какая фих разница, если ты ORDER BY задал, то LIMIT только после упорядочивания будет делаться. Если тем паче индексов нет по полям сортировки. А оно тебе надо -3400000 записей сортировать и выводить? Может взять таки нормальную порцию (по индексам) и уж в ней упорядочивать и т.п.
Maxim Timofeyev
Дата: 13.02.2004 21:48:33
Писал писал ответ -- а он куда-то пропал... ;(

К сожалению в SQL я не большой знаток, а писать надо. Так что если что-то неправильно напишу -- сильно не пинайте...

На всякий случай еще раз:
OS Linux, PostgreSQL v 7.4.1, RAM 512Mb, swap 2Gb
БД занимает на диске около 2,4Gb = 3'400'000 записи.

У меня база содержит несколько таблиц, объединенных через внешние ключи с главной таблицей.

Проблемы следующие:
1. Есть поле типа DATE. Я задал интервал day > '01/01/1980' AND day < '31/12/1983' ORDER BY ...
В результате просто получил сообщение, что не хватило памяти!
Без ORDER BY psql выел 2,4Gb, но результат вывел.
Да, индекс на это поле я создал... Производительность не увеличилась ни на грамм от появления индекса. ;(
Хотя вроде есть какая-то функция для интервалов дат или я не прав?

2. В таблице есть ID типа BIGSERIAL PRIMARY KEY, т.е. индекс строится автоматически.
Так вот поиск по полю ID (id=num) занимает у меня около минуты! При этом у меня есть четыре поля (улица, дом, корп, кв) по которым создан индекс, поиск по этим значениям приводит к практически моментальному ответу! Почему по ID так долго?!!

Заранее благодарен за ответы!
Sad Spirit
Дата: 14.02.2004 00:09:26
Maxim Timofeyev

1. Есть поле типа DATE. Я задал интервал day > '01/01/1980' AND day < '31/12/1983' ORDER BY ...
В результате просто получил сообщение, что не хватило памяти!
Без ORDER BY psql выел 2,4Gb, но результат вывел.
Да, индекс на это поле я создал... Производительность не увеличилась ни на грамм от появления индекса. ;(
Хотя вроде есть какая-то функция для интервалов дат или я не прав?

Делался ли для таблицы VACUUM ANALYZE?
Что говорит EXPLAIN о запросе?
Сколько реально записей попадает в интервал? Нужны ли сразу все?


Maxim Timofeyev

2. В таблице есть ID типа BIGSERIAL PRIMARY KEY, т.е. индекс строится автоматически.
Так вот поиск по полю ID (id=num) занимает у меня около минуты! При этом у меня есть четыре поля (улица, дом, корп, кв) по которым создан индекс, поиск по этим значениям приводит к практически моментальному ответу! Почему по ID так долго?!!

Потому что числовая константа по умолчанию считается типа int4.
Приводи к int8

... WHERE id = num::int8;

или заключай в кавычки

... WHERE id = 'num';
Sad Spirit
Дата: 14.02.2004 00:11:27
Имелось в виду

"Потому что числовая константа по умолчанию считается типа int4, и индекс по полю типа int8 не используется."
Maxim Timofeyev
Дата: 14.02.2004 00:35:33
Sad Spirit
Делался ли для таблицы VACUUM ANALYZE?


Да. В какой именно момент я не помню, но проверял...
Вот почти только что опять попробовал задать интервал дат (RAM увеличил до 1Gb) --
тот же эффект. НЕ ХВАТАЕТ ПАМЯТИ! ;( Куда уж еще? Судя по top'у он ее всю не
расходует... ;(

Вот что пишет:
ERROR: не хватает памяти
DETAIL: Failed on request of size 8224.

В логе:
[ еще целая куча поскипана ]
DynaHash: 8192 total in 1 blocks; 6912 free (0 chunks); 1280 used
DynaHashTable: 8192 total in 1 blocks; 5080 free (0 chunks); 3112 used
DynaHashTable: 8192 total in 1 blocks; 2008 free (0 chunks); 6184 used
DynaHashTable: 8192 total in 1 blocks; 2008 free (0 chunks); 6184 used
DynaHashTable: 8192 total in 1 blocks; 1984 free (0 chunks); 6208 used
DynaHashTable: 8192 total in 1 blocks; 3520 free (0 chunks); 4672 used
DynaHashTable: 24576 total in 2 blocks; 13240 free (4 chunks); 11336 used
DynaHashTable: 0 total in 0 blocks; 0 free (0 chunks); 0 used
DynaHashTable: 0 total in 0 blocks; 0 free (0 chunks); 0 used
DynaHashTable: 0 total in 0 blocks; 0 free (0 chunks); 0 used
DynaHashTable: 0 total in 0 blocks; 0 free (0 chunks); 0 used
DynaHashTable: 0 total in 0 blocks; 0 free (0 chunks); 0 used
ErrorContext: 8192 total in 1 blocks; 8176 free (3 chunks); 16 used

Sad Spirit
Потому что числовая константа по умолчанию считается типа int4.
Приводи к int8


Спасибо! Вылетает тоже мгновенно! Я об этом н знал!..
А в каких случаях подобная проблема с индексами может еще проявлятся?
Sad Spirit
Дата: 15.02.2004 14:49:31
Maxim Timofeyev

Да. В какой именно момент я не помню, но проверял...
Вот почти только что опять попробовал задать интервал дат (RAM увеличил до 1Gb) --
тот же эффект. НЕ ХВАТАЕТ ПАМЯТИ! ;( Куда уж еще? Судя по top'у он ее всю не
расходует... ;(

Вот что пишет:
ERROR: не хватает памяти
DETAIL: Failed on request of size 8224.

В логе:
[ еще целая куча поскипана ]

Информации много, но вся абсолютно бесполезна. Давай-ка приведи:
1) Схемы участвующих в запросе таблиц;
2) Полный текст запроса, а не только "попробовал задать интервал дат";
3) Вывод команды EXPLAIN для этого запроса.
Maxim Timofeyev
Дата: 16.02.2004 15:00:59
автор
Информации много, но вся абсолютно бесполезна. Давай-ка приведи:
1) Схемы участвующих в запросе таблиц;Информации много, но вся абсолютно бесполезна. Давай-ка приведи:
1) Схемы участвующих в запросе таблиц;
2) Полный текст запроса, а не только "попробовал задать интервал дат";
3) Вывод команды EXPLAIN для этого запроса.
2) Полный текст запроса, а не только "попробовал задать интервал дат";
3) Вывод команды EXPLAIN для этого запроса.


Ok. Сейчас база отдана в работу и вроде даже работает. Поиск по датам пока не критичен. Постараюсь на днях добрести до базы и все еще раз перепроверить...

P.S. Существует ли какая-нибудь информация о применении PostgreSQL и объемах БД?
Мне скоро могут подкинуть заказ на значительно большие объемы данных...

Существуют ли какие-нибудь рекомендации по проектированию БД и где вообще можно об этом почитать новичку?

Заранее спасибо!

Немного о таблицах в обсуждаемой БД:
Есть главная таблица, назовем ее main. В ней 1 (id) PRIMARY KEY и 4 FOREIGN KEY
Есть еще четыре подчиненные таблицы. У них всего два поля:
id primary key и name. запрос (через VIEW, хотя и без нее столько же по времени) выбирает значения из таблицы main объеденяя с выборкой из остальных четырех таблиц.
При поиске в main по полю id -- вывод происходит мгновенно (после применения id='num', id у меня bigserial primary key). проблемы пока остались при update и поиску по датам...
Sad Spirit
Дата: 17.02.2004 20:04:59
Maxim Timofeyev
P.S. Существует ли какая-нибудь информация о применении PostgreSQL и объемах БД?
Мне скоро могут подкинуть заказ на значительно большие объемы данных...

На сайте написано
Maximum size for a database: unlimited (4 TB databases exist)

Maxim Timofeyev
Существуют ли какие-нибудь рекомендации по проектированию БД и где вообще можно об этом почитать новичку?

Если давит жаба, то на citforum.ru есть неплохие материалы. Если не давит, то купить Дейта "Введение в системы баз данных".
Maxim Timofeyev
Дата: 11.03.2004 12:30:57
Что-то давно я сюда не заглядывал...

автор
Maximum size for a database: unlimited (4 TB databases exist)


Спасибо.

автор
Если давит жаба, то на citforum.ru есть неплохие материалы. Если не давит, то купить Дейта "Введение в системы баз данных".


Для хороших вещей жаба не давит. Постараюсь найти.
А сколько она приблизительно стоит?