В догонку к autovacuum. Если раньше в базе с 4.5 млн. записей мне приходилось чуть ли не каждую пятницу делать vacuum full (база прилично тормозит при этом), то начиная с beta я вообще забыл что это такое, страшное слово vacuum. И как я этому рад... ;-)

хорошая новость, пойду качать, ставить. вот

Кошмар... mysql 3.23.58 - таблица 20 гигов - 35 миллионов записей. Ничего не тормозит, работает как часы. Нда...

mysql> select count(*) from traffic;

+----------+

| count(*) |

+----------+

| 34033826 |

+----------+

1 row in set (0.00 sec)

Ну и накой нужна такая субд как постгре когда есть mysql?

ЛОР уже проапгрейдили?

Кстати, log1n, а можно поинтересоваться конфигурацией сервера? Это так... соц. опрос.

а что пэжэ не умеет достать из памяти проиндексированную цифирьку ?

>1 row in set (0.00 sec)

А там случайно после use database; не жужжал винт некоторое время перед использованием этого запроса?

изобрази-ка такой:

SELECT * FROM traffic WHERE A like(%a%);

, где A - символьное или полнотекстовое не индексированное поле;

а - любая распространенная буква используемого в значениях поля алфавита

совершенно очевидно, что выборка по такому объему не возможна за 0 сек. в силу физических ограничений винтов и рамы, значение просто было дернуто из служебной информации

Поставить что-ли. Кто хочет такую базку?

PostgreSQL 8.1: официальный пресс-релиз

СРОЧНО В НОМЕР

## 8 ноября 2005, Франкфурт, Германия (OpenDBCon):
Международная команда разработчиков PostgreSQL объявила о
выпуске PostgreSQL 8.1 - ведущей системы управления базами данных с
открытым исходным кодом.
Разработанная большим и постоянно растущим сообществом, активно
поддерживаемая корпоративными спонсорами, версия 8.1 расширила
возможности разработки приложений PostgreSQL. В новой версии
улучшена производительность, реализованы расширенные средства SQL
для поддержки больших хранилищ данных, обработки большого числа
транзакций, а также более сложного распределенного корпоративного
программного обеспечения.

Новые возможности СУБД позволят занять еще более прочные
позиции, заложенные предыдущей версией продукта. Версия 8.0 в первые
7 месяцев после выпуска была загружена миллион раз, по сравнению с 300
000 за такой же период предыдущей версии.

"Проект завоевывает популярность среди пользователей баз данных",
говорит Ланс Обермайер, директор по продуктам фирмы Pervasive
Software, одного из корпоративных спонсоров PostgreSQL. "Учитывая
растущий интерес к инфраструктурному программному обеспечению с
открытым исходным кодом, мы ожидаем еще большего энтузиазма по
отношению к PostgreSQL."

Новые расширенные возможности
------------------------------

Роли: PostgreSQL теперь поддерживает роли, упрощая управление
большим числом пользователей со сложными перекрывающимися
наборами прав.

Параметры IN/OUT: функции PostgreSQL теперь поддерживают
параметры IN, OUT и INOUT, что существенно улучшает поддержку
сложной бизнес-логики для приложений J2EE и .NET.

Двухфазная фиксация транзакций: необходимая для приложений в
глобальных сетях и гетерогенных дата-центрах, использующих
PostgreSQL, эта функция позволяет проведение ACID-совместимых
транзакций среди распределенных серверов.

Усовершенствования производительности
--------------------------------------

Увеличение производительности в многопроцессорных системах
(SMP): диспетчер буферизации в версии 8.1 был усовершенствован для
практически линейного масштабирования с ростом числа процессоров,
давая значительный прирост производительности на 8-, 16-процессорных,
двуядерных и многоядерных системах.

Сканирование битовых карт: при необходимости индексы будут
автоматически преобразованы в битовые маски в памяти, что дает
двадцатикратное повышение производительности индексации на сложных
запросах к большим таблицам. Это также упрощает управление базами
данных, значительно сокращая необходимость в мультистолбцовых
индексах.

Секционирование таблиц: планировщик запросов теперь может
избегать сканирования целых секций большой таблицы, пользуясь
техникой, известной как "исключение на основе ограничений". Сходная с
"секционированием таблиц" других СУБД, эта возможность улучшает
производительность и упрощает управление данными в многогигабайтных
таблицах.

Разделяемая блокировка строк: "блокировка лучше, чем на уровне
строк" PostgreSQL теперь поддерживает еще более высокий уровень
параллелизма за счет добавления разделяемой блокировки строк для
внешних ключей. Разделяемая блокировка строк повысит производительность вставки и
обновления данных для многих OLTP-приложений.

"PostgreSQL 8.1 выигрывает в производительности практически на
всех операциях [на наших] двухпроцессорных Opteron-серверах", говорит
Мерлин Монкур, администратор баз данных фирмы Reliable Computer
Solutions. "Конкретнее, я наблюдаю 20-процентное сокращение времени
выполнения простых запросов и дополнительно 20-процентное
сокращение нагрузки на CPU, с улучшением показателей общей нагрузки
на сервер от 20 до 40 процентов."

Предлагается еще более 120 других улучшений, некоторые из них
описаны в материалах для прессы версии 8.1:
http://www.postgresql.org/about/press/presskit81.html.ru


О PostgreSQL
---------------

PostgreSQL -- это коллективный продукт сотен разработчиков,
основанный на двух десятилетиях работы, начавшейся в Калифорнийском
Университете в Беркли.
С поддержкой возможностей, необходимых для крупных организаций,
таких, как транзакции, функции, триггеры и вложенные запросы,
PostgreSQL используется сегодня многими фирмами и
правительственными учреждениями с самыми высокими требованиями.
PostgreSQL распространяется под лицензией BSD, допускающей
использование и распространение без каких-либо отчислений как для
коммерческих, так и для некоммерческих приложений.

Сравнивать MySql 3-4 c PostgreSQL как минимум не корректно, поскольку это разные весовые категории. Так что прошу воздержитесь от высказываний построенных на эмоциях. А вот было бы интересно получить сравнительный обзор таких промышленных СУБД MaxDB и PostgreSQL 8, но специалистов хорошо знающих и то и другое, и способных объективно оценить это видимо не много и на дороге они не валяются(на лоре). Лично для меня конечно в глаза бросается различные лицензионные политики MySql - gpl или commerc, а PostgreSQL - BSD. Так что хорошо, что они оба есть.

> Кстати, log1n, а можно поинтересоваться конфигурацией

> сервера? Это так... соц. опрос.

Гиг оперативки, двойной зион 2.4, 5 SCSI винтов в пятом рейде.

> mysql> select count(*) from traffic;

А часто в этой табличке изменяются или удаляются существующие строки?

> совершенно очевидно, что выборка по такому объему не

> возможна за 0 сек. в силу физических ограничений винтов и

> рамы, значение просто было дернуто из служебной информации

Да какая разница за сколько секунд он посчитал количество записей? оно вообще могло закэщироваться, я несколько раз опрашивал. Главное тут размер таблицы и 35 миллионов записей (это биллинг в локалке, а как срут всякие сассеры и мсбласты вы вкурсе :)). И всё пашет замечательно третий год!

> А часто в этой табличке изменяются или удаляются

> существующие строки?

Раз в 15 минут добавляются по несколько тысяч и раз в сутки удаляются по нескольку сот тысяч. Это биллинг NetUP UTM. Слышали про такой?

Один раз в жизни я посмотрел на MySQL.

Один гордый товарищ разбирался с netflow... Ну позапускал там скрипты от Cisco и все такое. Получил базу примерно в 50 тыс. записей. Ничего с базой не делали, а получили состояние, что на count(*) MySQL дает ответ мгновенно, а записи извлечь из базы не может... ни одной, любой select ничего не дает...

> Раз в 15 минут добавляются по несколько тысяч

Это пока фиолетово...

> раз в сутки удаляются по нескольку сот тысяч.

А после удаления analize table не делается?

>Это биллинг NetUP UTM

Это вы про изделие, которое покупают, чтобы бумажка (сертификат) был: http://forum.nag.ru/viewtopic.php?t=9072

> А после удаления analize table не делается?

Нет. Раз в месяц-два захожу, и ручками делаю optimize table traffic;

> Это вы про изделие, которое покупают, чтобы бумажка

> (сертификат) был: http://forum.nag.ru/viewtopic.php?t=9072

И да и нет. Да, чтобы сертификат был, нет - это значит четверка работает вполне сносно на 500-700 юзеров. Терпимо. Главное, после десятка апдейтов всё довольно стабильно, без сюрпризов.

> Раз в месяц-два захожу, и ручками

Ага, значит делаешь vacuum ручками "раз в месяц-два".

> делаю optimize table traffic

И что в это время с производительностью? Как долго таблица остаётся залоченной?

До кучи ещё вышел MSSQL http://developers.slashdot.org/article.pl?sid=05/11/07/2150215&from=rss

> Раз в 15 минут добавляются по несколько тысяч и раз в сутки удаляются по нескольку сот тысяч. Это биллинг NetUP UTM. Слышали про такой?

для задач типа сбора статистики или пароли/настройки юзеров хранить mysql - самое оно.

там где нужно еще и обрабатывать (не путать с sum,avg,count) информацию, postgresql будет гораздо эффективнее. а если еще и _нормальные_ транзакции и ссылочная целостность важна, тогда postgresql вне конкуренции. конечно же, коммерческие базы типа informix, db2, oracle обладают еще более ценными качествами, но они, порой, полностью нигелируются стоимостью или сложностью сопровождения.

нет плохих баз, есть неудачный выбор базы под решаемую задачу.

А не знает ли кто как там насчёт применения функции UPPER к строкам в UTF8 и содержащим руские символы?

В 8.0 это не работает.

Вот это вот: > mysql> select count(*) from traffic;

берет циферку из метаданных таблицы, которая меняется при каждом изменении таблицы. Постгрес не хранит это в метаданных, поэтому у него каунт считается дольше. Для сравнения нужно использовать селект с условием (что на практике чаще и используется), тут уже метаданные не помогут.

>>Ну и накой нужна такая субд как постгре когда есть mysql?

Ну дык нарисуй под мускул че нить посложнее чем систему учета траффика из двух (трех?) таблиц. Поймешь для чего нужна субд уровня постгри.

В последние версии мускула декларативную целостность,триггеров да хранимых процедур добавили - видно хотят функциональность подтянуть до уровня нормального sql сервера. Кстати со всеми этими фичами он значительно тормознее своих облегченных предков.

Вроде ж нетап в 5-й версии траффик на GigaBase движок вынесли.

как там с оптимизацией выборок из views?

Помогите пожалуйста - вопрос по оптимизатору постгреса.. Допустим есть таблица с индексом и view который почти целиком из нее данные берет:
create table t1 (when datetime,v int);create index i1 t1(when);
create view v1 as select * from t1 union select now(),0; --такой тупой view
select * from v1 where when > '2005-11-01'; -- в моих условиях вернется меньше 1% записей.
В версиях 7.x (точно пробовал 7.2.x) последниий запрос НЕ ИСПОЛЬЗУЕТ индекс i1 нифига. А у меня в таблице t1 до 100k записей, и постгрес начинает насиловать диск и тормозить.

Внимание вопрос: это исправлено в версии 8.x?
Вопрос2: а у кого из других СУБД с этим нормально? Надеюсь, у Oracle все ОК?
Спасибо за ответ заранее! Очень уж достала эта проблема в постгресе..

> select * from v1 where when > '2005-11-01'; -- в моих условиях
вернется меньше 1% записей.

Да, забыл добавить - выборка из самой таблицы t1:
select * from t1 where when > '2005-11-01';
индекс конечно использует, и выполняется за доли секунды.. А из view - секунд 30..

> индекс конечно использует, и выполняется за доли секунды.. А из view - секунд 30..

Что естественно несерьезно для чего-то, называемого SQL сервером.. Забыл добавить - ничего старше чем 7.2.x не пробовал - посему и спрашиваю. А еще засада с postgresql - то что от версии к версии они что-то меняют в синтаксисе, и поэтому sql dump полученный на одной версии на новую версию не всегда встает (обычно проблемы с хитрыми определениями views возникают). Поэтому я избегаю погони за последними версиями постгре.

Ээээ.. у меня в семерке это работает... Неужели в 8 сломали?

>>Помогите пожалуйста - вопрос по оптимизатору постгреса.. Допустим есть таблица с индексом и view который почти целиком из нее данные берет:

Так и не должен имхо юнион индекс юзать. Индекс распространяется на таблицу, юнион - объединение нескольких таблиц (в общем случае). Крикнул юнион - забудь про индекс. То же самое если отбор идет по части поля типа when like '%05%'. Это не баг. Баг - это ваш запрос. Нафига выбирать запросом вещи очевидные (сегодня - ноль)?

Ты любитель нестандартного секса? ;) Где ж оно тебе индекс возьмет если его в представлении нет (и не будет). Делай выборку из таблицы, будут тебе индексы.

Кстати, может кто подскажет,можно ли постгрю заставить пользовать индексы в запросах вида when like '%...%'?

> Так и не должен имхо юнион индекс юзать. Индекс распространяется на таблицу, юнион - объединение нескольких таблиц (в общем случае). Крикнул юнион - забудь про индекс. То же самое если отбор идет по части поля типа when like '%05%'. Это не баг. Баг - это ваш запрос. Нафига выбирать запросом вещи очевидные (сегодня - ноль)?

Ну это называется абстракция (зачем вообще view тогда придумали?!). Неужели оракл тоже не умеет использовать индекс в таких случаях? Не верю!!! Хороший оптимизатор же может все это оптимизировать пользуясь дистрибьютивностью where относительно union.

Можно ... но нужно пристально доку почитать где сказаны ОГРАНИЧЕНИЯ как минимум если: - поиск текста "с начала" (like '..%') - ЛОКАЛИ!!! - ... По моему об этом даже в FAQ писали. Хочется полнотекстного поиска - загляните в контрибы - там уже есть ...

тому кто запросы более извращенные составляет чем select count(*) .. Кстати а в MySQL vacuum только только начинает появляться в то время как Postgres от него избавляется ...

2logIn:
>Ну и накой нужна такая субд как постгре когда есть mysql?
А ты к базе только select count(*) делаешь? тогда тебе вообще базы не нужно :)

> И что в это время с производительностью? Как долго таблица

> остаётся залоченной?

Минут 40. Раз в два месяца - не критично, ибо можно приостановить сброс статистики с коллектора в базу.

>Минут 40. Раз в два месяца - не критично, ибо можно приостановить сброс статистики с коллектора в базу.
Интересно чем это отличается от vacuum ?
недокументированная фича ? :))))

> Ты любитель нестандартного секса? ;) Где ж оно тебе индекс возьмет если его в представлении нет (и не будет). Делай выборку из таблицы, будут тебе индексы.

За этим и нужен "оптимизатор", чтобы разобраться как выгоднее исполнить запрос. Если интеллекта не хватает у него сообразить внести условие в подзапросы, то ничего не поделать, приходится прикладывать свой.

>Секционирование таблиц: планировщик запросов теперь может избегать cканирования целых секций большой таблицы, пользуясь техникой, известной как "исключение на основе ограничений". Сходная с "секционированием таблиц" других СУБД, эта возможность улучшает производительность и упрощает управление данными в многогигабайтных таблицах.

Это что table partitioning что ли? Если это не пездеж то ведь это просто СУПЕР!!! Хо-хо! Нахрена таперича нужны Informix WG или Db2 WG? A?

и в восьмерке upper/lower работает, надо просто initdb правильный делать. сам на это наступал, спасибо в русской рассылке по pg помогли

>>Ну это называется абстракция (зачем вообще view тогда придумали?!)

Кстати. Тормоза с viev свойственны не токмо постгри, такое часто случается и с пропиетарным. В вашем случае ести смысл сделать view без юниона и сравнить скорость простого селекта, выборки из view без юниона, и из view с юнионом.

Майкрософт sql (насколько я помню) индексирует свои view, впрочем могу и ошибаться.

Оптимизировать запрос к виду в его стандартной реализации (просто строка на сервере ?) , задача нетривиальная.

ЗЫ

Коль скоро вам нужно смотреть запись "сегодня ноль" - добавте ее в таблицу.

> Майкрософт sql (насколько я помню) индексирует свои view, впрочем могу и ошибаться.

А про оракл не в курсе?

> Оптимизировать запрос к виду в его стандартной реализации (просто строка на сервере ?) , задача нетривиальная.

Почему это просто строка? Я надеюсь, внутри сервера это обрабатывается как

select * from (select * from t1 union select now(),0) where 1>'2005-11-01';

и не удивлюсь если постгрес тут индексы (если прямо такой запрос вбить) применит.

> Коль скоро вам нужно смотреть запись "сегодня ноль" - добавте ее в таблицу.

Долго об[яснять - но в моей ситуации это не выход. Подумываю реализовывать stored procedures и делать выборку из них - в надежде что все через индексы будет работать. Но правда софт придется переколбашивать, а мне это НЕ ХОЧЕТСЯ.

> create view v1 as select * from t1 union select now(),0; --такой тупой view

view реально тупой: union выкидывает из результата повторяющиеся строки. Попробуй вместо union вставить union all

>> И что в это время с производительностью? Как долго таблица остаётся залоченной?

> Минут 40.

Всё понятно, спасибо. Вопросов больше не имею.

> Раз в два месяца - не критично, ибо можно приостановить сброс статистики с коллектора в базу.

К сожалению бизнес не может позволить "раз в два месяца по 40 минут на каждую таблицу" остановливать базу данных. Простой vacuum (не full) таблицу не лочит, на производительности сказывается слабо.

>Это что table partitioning что ли? Если это не пездеж то ведь это >просто СУПЕР!!! Хо-хо! Нахрена таперича нужны Informix WG или Db2 WG? >A?

Нет это пока её предшественник, очень близкий. Из этого можно сделать tb, но пока много придётся руками делать. Скоро вся рутина будет автоматом генериться и тогда это будет полноценной tb.

2anonymous (*) (08.11.2005 17:21:48)

> select * from (select * from t1 union select now(),0) where 1>'2005-11-01';

select * from (select * from t1 where when > '2005-11-01') union select now(),0;

переписать нельзя?