>http://dev.mysql.com/tech-resources/features.html

Postgre там однако староват ;)

>Скоро ( в течении недели ) должна появиться платформа 1С:8.1 в которой можно будет работать с PostgreSQL ( и под Линуксом и под Виндой). Пока только бета, но гдето через 2 месяца и релиз выйдет - тогда можно будет на боевых базах сравнивать MS и PG.

Кроме того 1С не собирается завязываться с MSSQL 2003

>Надеюсь удовлетворю всех тех, кто хочет устроить флейм на тему "а вот мускуль..., а постгрес"... http://dev.mysql.com/tech-resources/features.html

Нет - флейм продолжится! ;) Даже по этой табличке Postgre самый богатый на функции, кроме того очень многие типы и функции, которых согласно этой таблице нет, на самом деле присутствуют (или их аналоги).

2GladAlex

mssql2003 в природе не существует. есть mssql 2005.
и под ним что 1с семерка, что 1с восьмерка, прекрасно работают.

Ну я в этих версиях не особо разбираюсь - не интересно (помню SQL 2000 сильно ругали: отключила Азию от Инета надолго - перешли на Линукс ;)

А здесь ссылка пробегала: "Тут можно отметить и еще один важный момент: разработчики из "1С", продолжая делать главную ставку на Windows (основной код "1С:Предприятия" реализован на клиентской части, а планов использования другой настольной ОС у фирмы пока нет), явно избегают разговоров о переводе своей системы в архитектуру .NET. Вот и на последней партнерской конференции не было речи об использовании нового SQL Server 2005 или о подготовке к переходу в Windows Vista и Windows Server Longhorn."

http://www.pcweek.ru/?ID=510842

> Maximum Field Size 1 GB

Что, серьёзно? В PostgreSQL в BLOB-ах нельзя хранить ISO-шки DVD-фильмов? Кому тогда нужна такая пионерская поделка - у нас на втором курсе на лабах народ более серьёзные базы делал...

BLOB не регулярное поле. Его длина не ограничена 1Gb. Это ограничение касается текста, bytea, массивов

>Есть ли у кого примеры применения PostgreSQL для больших баз (работа с населением)? Может ли PG тягаться с MSSQL? Как работает на многопроцессорных системах - два двухядерных процессора? Фирма разработчик рекомендует MSSQL+MS Server 2003, хотелось бы Linux+PG?

Letaet. http://web.givex.com/

Tam bolee 30 dvuhprocessornih serverov s PGSQL.

Поздравления! Отличная СУБД! ;-)

> Кстати, раз пошла такая пьянка, делаем финт ушами:

+1

или alter table в транзацкии.

> "Each connection to the database does everything with 1 process. Since PostgreSQL is not threaded this means it can use only one CPU per connection."
и что ?
обясни в контексте отсуствия parallel query execution, чем mysql лушче

Лучшая БД в своём классе! Мои поздравления!

кривая обработка view в постгресе

Давеча чуть не упал под стул когда увидел как этот постгрес обрабатывает view.

Создал года 2 назад view чтобы можно было получать список клиентов, купивших продукт менее года назад, чтобы слать им бесплатные апдейты (кто больше назад купил продукт - должен заплатить чтобы получить еще год апдейтов):

create view cust_to_update as select whendate,prodnick,email from customers where purchasedate > (date 'now' - interval '1 year');

И как-то заметил что этот view показывает емейл первого клиента, купишвего продукт 3 года назад. Сделал

\dv cust_to_update

оказалось ЧТО ЭТО ПОДЕЛИЕ ИСПОЛЬЗОВАЛО ДАТУ СОЗДАНИЯ VIEW, а не текущую дату в этом месте date 'now'

Очевидно из-за того что внутреннее представление view - есть некоторая скомпилированая форма.

Из-за этого мы попали на бабки (рассылая апдейты людям, которые их не должны были получать, а должны были покупать)..

Надеюсь в других СУБД такой проблемы нет.

Версия: postgresql-7.2.1-5

PS: может кто знает как правильно сделать такой view в этом поделии?

В документации в 3 разных местах (а может и больше) эта ситуация описана!

> ... Из-за этого мы попали на бабки ...

Странно, что не ты сам попал на бабки. Инструмент нужно знать. Так себе можно и не то отрезать... :)

этим он будет себя утешать после того как шеф израсходует весь вазелин и немного устанет ;)

> В документации в 3 разных местах (а может и больше) эта ситуация описана!

> saper *** (*) (12.07.2006 10:32:54)

А можно ключевые слова по каким искать? Или примерное название чаптера? Или солюшн?

А ANSI SQL стандарт разве такие вещи не регламентирует? Это ж бред.

кривой оптимизатор бесит со view

Еще очень жалею что используем psql в другом комм проекте из-за убого оптимизатора в постгресе. Очень хочется уйти с этого поделия на нормальную коммерческую СУБД (бесплатных много уже: SAP, IBM DB2 express) - да код лень переделаывать, и кастомеры по всему СНГ разбросаны.

Это здесь мы уже обсуждали.

Напоминаю:

create table t1 (whentime datetime, amount int); create index t1i on t1(whentime);

create view v1 as select from t1 where whentime > '2006-01-01';

Так вот, запрос к таблице - использует индекс:

select sum(amount) from t1 where whentime > '2006-01-01';

А запрос к view не использует: select sum(amount) from v1;

Даже если в таблице t1 есть 100k записей со значениями 'whentime' от 1971-01-01 до сегодня с шагов в час.

Проверяли вывод explain на всех версиях и платформах - индекс при выборке из view она не думает использовать (вернее, 1 ч-к и 10 сказал что видит использование индекса в explain но все остальные с той же версией постгри видели что индекс не юзается).

vacuum analyze;

делали естественно перед просмотром explain.

Из-за этого система использующая постги тормозит все больше и больше с каждым месяцем, мля.

Никто не в курсе, они это планируют исправить вообще?

А в форках постгри - типа enterprisedb.com - это исправлено?

> create view cust_to_update as select whendate,prodnick,email from customers where purchasedate > (date 'now' - interval '1 year');

create view cust_to_update as select whendate,prodnick,email from customers where purchasedate > (CURRENT_TIMESTAMP - interval '1 year');

http://www.postgresql.org/docs/8.1/interactive/functions-datetime.html#FUNCTI...

> оказалось ЧТО ЭТО ПОДЕЛИЕ ИСПОЛЬЗОВАЛО ДАТУ СОЗДАНИЯ VIEW, а не текущую дату в этом месте date 'now'

и что собственно говоря не так ? где то написано что должно происходить иначе

> Из-за этого мы попали на бабки (рассылая апдейты людям, которые их не должны были получать, а должны были покупать)..

поздравляю, но postgresql тут yt причем

> А ANSI SQL стандарт разве такие вещи не регламентирует? Это ж бред.
а вы его видели ?
он регламентирует CURRENT_TIMESTAMP
и postgresql это реализует

> Из-за этого мы попали на бабки (рассылая апдейты людям, которые их не должны были получать, а должны были покупать)..

классический пример /dev/hands и /dev/brains
вам уже объяснили, что вы пытаетесь критиковать ПО, которое не знаете. Подучитесь сначала.

ps.
1. у вас есть отдел тестирования?
2. как называется ваш продукт?

Версия постгреса какая?

Вот пример:

test=# EXPLAIN ANALYZE select sum(amount) from t1 where whentime > '2006-01-01'; QUERY PLAN -------------------------------------------------------------------------------- ------------------------------------ Aggregate (cost=21.92..21.93 rows=1 width=4) (actual time=0.030..0.031 rows=1 loops=1) -> Bitmap Heap Scan on t1 (cost=3.06..20.44 rows=590 width=4) (actual time=0.022..0.022 rows=0 loops=1) Recheck Cond: (whentime > '2006-01-01 00:00:00'::timestamp without time zone) -> Bitmap Index Scan on t1i (cost=0.00..3.06 rows=590 width=0) (actual time=0.015..0.015 rows=0 loops=1) Index Cond: (whentime > '2006-01-01 00:00:00'::timestamp without time zone) Total runtime: 0.130 ms (6 rows)

test=# EXPLAIN ANALYZE select sum(amount) from v1; QUERY PLAN -------------------------------------------------------------------------------- ------------------------------------ Aggregate (cost=21.92..21.93 rows=1 width=4) (actual time=0.030..0.032 rows=1 loops=1) -> Bitmap Heap Scan on t1 (cost=3.06..20.44 rows=590 width=4) (actual time=0.022..0.022 rows=0 loops=1) Recheck Cond: (whentime > '2006-01-01 00:00:00'::timestamp without time zone) -> Bitmap Index Scan on t1i (cost=0.00..3.06 rows=590 width=0) (actual time=0.016..0.016 rows=0 loops=1) Index Cond: (whentime > '2006-01-01 00:00:00'::timestamp without time zone) Total runtime: 0.148 ms (6 rows)

test=# SELECT version(); version -------------------------------------------------------------------------------- ----------------- PostgreSQL 8.1.4 on i386-unknown-freebsd6.1, compiled by GCC gcc (GCC) 3.4.4 [FreeBSD] 20050518 (1 row)

Может, пора в консерватории чего-нибудь исправить?

Постгрес, имхо, местами чудноват. пару лет назад столкнулся с забавными граблями с RULES и полем SERIAL.

Коротко говоря, если есть таблица А с полем например id Serial, есть таблица Б с историей вставок и изменений (там поле соответствующее serial имеет тип integer) и правило на вставку и изменение, которое заносит новые и старые значения полей А в историческую таблицу Б, так вот значение поля A.id при вставке в историческую таблицу Б в виде id.new увеличивается на 1.

Т.е. при в ставке в А id принимает значения 1, 3, 5, а в Б - 2,3,6. Логика присутствует, но какая-то чудная. Триггеры спасли :) Что с этим сейчас в Постгресе? Исправили или так и работает? :)

Ситуация с датой создания объекта, имхо, тоже чудноватая какая-то. ?

create table t1 (whentime datetime, amount int);
ERROR: тип "datetime" не существует

а это точно про postgresql ?) юзаем timestamp

create index t1i on t1(whentime);
create view v1 as select * from t1 where whentime > '2006-01-01';

INSERT INTO t1 SELECT (timestamp '1971-01-01' + (q || ' hour')::interval) AS when, q AS amount FROM generate_series(0, 1000000) AS q;

SELECT COUNT (*), MIN (whentime), MAX (whentime) FROM t1;
count | min | max
---------+---------------------+---------------------
1000001 | 01.01.1971 00:00:00 | 28.01.2085 16:00:00
(1 запись)

VACUUM ANALYZE VERBOSE t1;
INFO: производится сборка мусора для "public.t1"
INFO: индекс "t1i" теперь содержит версий строки: 1000001, на страницах: 3818
DETAIL: страниц индекса удалено: 0, готово к переиспользованию: 0.
CPU 0.00s/0.02u sec elapsed 0.02 sec.
INFO: "t1": найдено 0 удалямых, 1000001 неудаляемых версий строки в страницах: 6370
DETAIL: 0 dead row versions cannot be removed yet.
There were 0 unused item pointers.
0 pages are entirely empty.
CPU 0.00s/0.07u sec elapsed 0.08 sec.
INFO: анализируется "public.t1"
INFO: "t1": scanned 3000 of 6370 pages, containing 471000 live rows and 0 dead rows; 3000 rows in sample, 1000090 estimated total rows
VACUUM

ed=> explain analyze select sum(amount) from t1 where whentime > '2006-01-01';
QUERY PLAN
-------------------------------------------------------------------------------- ----------------------------------------------
Aggregate (cost=18445.69..18445.69 rows=1 width=4) (actual time=1005.870..1005.870 rows=1 loops=1)
-> Index Scan using t1i on t1 (cost=0.00..16684.95 rows=704293 width=4) (actual time=0.020..649.955 rows=693184 loops=1)
Index Cond: (whentime > '01.01.2006 00:00:00'::timestamp without time zone)
Total runtime: 1005.933 ms
(записей: 4)

ed=> explain analyze select sum(amount) from v1;
QUERY PLAN
-------------------------------------------------------------------------------- ----------------------------------------------
Aggregate (cost=18445.69..18445.69 rows=1 width=4) (actual time=992.553..992.554 rows=1 loops=1)
-> Index Scan using t1i on t1 (cost=0.00..16684.95 rows=704293 width=4) (actual time=0.030..647.292 rows=693184 loops=1)
Index Cond: (whentime > '01.01.2006 00:00:00'::timestamp without time zone)
Total runtime: 992.627 ms
(записей: 4)

> vacuum analyze;
> делали естественно перед просмотром explain.
в некотрых версиях после analyze нужно перезапустить psql чтобы собраннай статистика использовалась


> Проверяли вывод explain на всех версиях и платформах
> Из-за этого система использующая постги тормозит все больше и больше с каждым месяцем, мля.
о смене профессии не задумывались ?

> Логика присутствует, но какая-то чудная.
не без этого:)
> Триггеры спасли :)
ИМХО, sequence/default nextval больше бы подошло

>> Триггеры спасли :)

> ИМХО, sequence/default nextval больше бы подошло

Я тоже так считал. Но уже было приложение работающее в промышленном режиме и общение с разработчиками было не слишком простым.

Про "чудность" с датой создания - беру свои слова обратно, невнимательно прочитал пост. Про TIMESTAMP 'now' в мануале написано. К слову, такая возможность где-то еще встречается, кроме PG? :)

> create table t1 (whentime datetime, amount int); > ERROR: тип "datetime" не существует

> а это точно про postgresql ?) юзаем timestamp

postgres 7.2.1 его прекрасно поддерживает. И оракл тоже, и многие СУБД. Значит в новых версиях постгреса выкинули.

В общем извиняюсь за смуту, просто забыл свои основные претензии. Индекс в том запросе используется даже для версии 7.2.

View надо создавать так:

create view v2 as select * from t1 union select now(),1;

Так вот запрос

select sum(amount) from v2 where whentime > '2006-01-01';

индекс не использует вроде бы даже на текущей версии постгреса.

Это обсуждалось здесь: http://www.linux.org.ru/jump-message.jsp?msgid=1163347#1165377

Оракл точно в таком случае индекс использует.

Сорри за смуту.

> вам уже объяснили, что вы пытаетесь критиковать ПО, которое не знаете. > Подучитесь сначала.

Просто везде view пиарятся как "view это фактически куски statements которые приписываются к вашему запросу перед исполнением" - или как-то так (из чего логично сделать вывод что вызов now() будет делаться каждый раз при выборки из view а не один раз при его создании).

> ps. > 1. у вас есть отдел тестирования?

Совмещает свои функции с другими отделами :-)

>>Скоро ( в течении недели ) должна появиться платформа 1С:8.1 в

Кстати, хороший будет тест. Базы аддинэс самые бестолковые по структуре и ооочень большие (по крайней мере у меня). Ежели пропишут еще модуль для подключения своего недомакроязыка к постгри.... Хотя вряд-ли. Кодить они давно разучились.

>>Фирма разработчик рекомендует MSSQL+MS Server 2003

Тоесть, помимо всего прочего, дя для двух процов хочет впарить вам крутой софт на 15 килобаксов, уверяя Вас что это круто, исключительно из за того что они больше ничего не знают? Назовите мне хоть одну фичу MSSQL которая бы потянула на новенький форд.

>В общем извиняюсь за смуту, просто забыл свои основные претензии. >индекс в том запросе используется даже для версии 7.2.

>View надо создавать так:

>create view v2 as select * from t1 union select now(),1;

>Так вот запрос

>select sum(amount) from v2 where whentime > '2006-01-01';

>индекс не использует вроде бы даже на текущей версии постгреса.

>Это обсуждалось здесь: >http://www.linux.org.ru/jump-message.jsp?msgid=1163347#1165377

>Оракл точно в таком случае индекс использует.

Да, если запрос именно таков - то индекс не используется Однако стоит сделать более логичный union по результатам из двух ТАБЛИЦ - и индексы начинают работать

1) Навига такой костыль в виде select now(),1 ?

2) примерчик из Оракла не покажете ?

>Создал года 2 назад view чтобы можно было получать список клиентов, купивших продукт менее года назад, [skip]

чудесная, просто эталонная илюстрация к поговорке про стеклянный х%й и дурака

> 1) Навига такой костыль в виде select now(),1 ?

Например нам надо строить график значения чего-либо от чего-либо. Например стоимости акции от времени. При условии что сделки могут совершаться от раз в секунду до раз в день, а правая граница графика чтобы имела текущее время. В итоге без такого view в котором union'ом добавляются цена последней сделки и текущее время мы проблему решаем (самый наивный путь, на самом деле - использовать такой view). Добавляется ИЗ ТАБЛИЦЫ стоимость последней сделки, естественно, а не фиксированная константа.

create table t2 (amount int);

insert into t2 values (545);

vacuum analyze t2;

create view v3 as select * from t1 union select now(),amount from t2;

select sum(amount) from v3 where whentime > '2006-01-01';

У меня в этом случае индекс тоже не используется. Посгри 7.2.

> 2) примерчик из Оракла не покажете ?

См. по моей ссылке на предыдущее обсуждение - там есть примерчик для оракла (с константой) и план исполнения.

>insert into t2 values (545);

> vacuum analyze t2;

А зачем это?

> postgres 7.2.1 его прекрасно поддерживает. И оракл тоже, и многие СУБД. Значит в новых версиях постгреса выкинули.
и правильно, нечего нестандартные типы разводить

> create view v2 as select * from t1 union select now(),1;
> select sum(amount) from v2 where whentime > '2006-01-01';
те в результате не самый травиальный запрос вида:
select sum(amount) from (select * from t1 union select now(),1) AS x where whentime > '2006-01-01';

> индекс не использует вроде бы даже на текущей версии постгреса.
да не использует, а какая то еще open source база использует ?

какая проблема развернуть:
SELECT sum(amount) from (select * from t1 where whentime > '2006-01-01' union [all] select now(),1 where now() > '2006-01-01') AS g;

> Про TIMESTAMP 'now' в мануале написано. К слову, такая возможность где-то еще встречается, кроме PG? :)
не замечал

> ИМХО, sequence/default nextval больше бы подошло так ведь и curval есть :)

Ставь новый Postgre - 8.1 и выше. В старых версиях 7.х в таких случаях индекс не использовался. Я использовал конструкции типа "..ORDER BY <foo> LIMIT 1" - тоже очень быстро работало и в документации они тож такой способ предлагали. Так что переходи на 8.1.х и dump/restore are welcome ;) А база отличнейшая!!! :)

>Постгрес, имхо, местами чудноват. пару лет назад столкнулся с забавными граблями с RULES и полем SERIAL.

Исправили давно - use 8.0.x/8.1.x/8.2.x

> какая проблема развернуть: > SELECT sum(amount) from (select * from t1 where whentime > '2006-01-01' union [all] select now(),1 where now() > '2006-01-01') AS g;

Просто есть генератор отчетов, и он оперирует только понятими таблиц и view. То есть ему на вход можно дать имя таблицы или view, а он сам спросит юзера про все срезы, фильтрацию, детализацию и тд и покажет из них график или табличку.

>А отукда такая информация? Обещали в июле сделать, но до сих пор в официальных источниках тихо все...

Сегодня вышла бета. Финальная появитсяв сентябре-ноябре.