LINUX.ORG.RU

PostgreSQL-события в сентябре-октябре в Москве


0

0

В ближайшее время в Москве состоится сразу несколько PostgreSQL-событий.

19 сентября в Москве компания Postgresmen организует 8-часовой семинар «Использование PostgreSQL. Особенности применения PostgreSQL в связке с 1C:Предприятие». Семинар проведут известнейшие специалисты PostgreSQL, члены PostgreSQL Global Development Group, разработчики большого количества популярных расширений PostgreSQL (в том числе патчей PostgreSQL, которые используются в 1C:Предприятие) Олег Бартунов и Фёдор Сигаев.

21 сентября в Москве организаторы конференции Highload-2007 и компания Postgresmen организуют 4-часовой семинар, посвящённый вопросам производительности PostgreSQL. Семинар проведёт один из основателей и действующий член Core Team PostgreSQL Брюс Момджан (Bruce Momjian). Семинар будет проведён на английском языке с синхронным переводом на русский.

24-25 сентября в Москве состоится конференция Highload-2007. С докладами, посвящёнными различным аспектам производительности PostgreSQL, выступят Брюс Момджан (Bruce Momjian) и Фёдор Сигаев.

2 октября в Москве на конференции, посвящённой пятилетию журнала «Системный администратор», с докладом «Что нового в PostgreSQL 8.3?» выступит Николай Самохвалов, технический директор компании Postgresmen.

>>> Подробнее о первом семинаре

Из анонса непонятно, будут ли участвовать в семинаре разрабы из 1С? Речь, насколько я понимаю, будет идти о версии 8.*.

Sun-ch
()

даже сказать нечего :) хорошо

Mikael
()

Видео выложат, самое главное? Особенно про чего нового в 8.3?

GladAlex ★★★★★
()
Ответ на: комментарий от Sun-ch

8.1 поддерживает PostgreSQL в качестве сервера.
>Правда 1С:Предприятие 8 имеет некоторые особенности работы с СУБД >PostgreSQL, связанные с использованием транзакционных блокировок:
>в режиме автоматического управления блокировками в транзакции >используются табличные блокировки СУБД;
>в режиме управляемых блокировок в транзакции используются блокировки >записей и полей СУБД.

Когда позвонил в техподдержку, и спросил, как у них насчёт блокировок в типовых конфигурациях в случае с PostgreSQL, получил ответ, что если под виндой - ставь MSSQL, если под LINUX - DB2.

anonymous
()
Ответ на: комментарий от anonymous

Серьезно так сказали? Можешь их нафиг послать, тебе ведб продали продукт с поддержкой постгреса, вот и требуй ее

anonymous
()
Ответ на: комментарий от anonymous

> Серьезно так сказали? Можешь их нафиг послать, тебе ведб продали продукт с поддержкой постгреса, вот и требуй ее

Послать может, конечно.

Только типовые конфигурации 1С используют в PostgreSQL табличные блокировки, что большинству заказчиков не подходит.

anonymous
()
Ответ на: комментарий от Sun-ch

> DB2 используется в той же нише рынка что и оракл. И цены, надо полагать, того же порядка.

DB2 Express-C is a version of DB2 Express Edition (DB2 Express) for the community. DB2 Express-C is a no-charge data server for use in development and deployment of applications including: XML, C/C++, Java, .NET, PHP, and more. DB2 Express-C can be run on up to 2 dual-core CPU servers, with up to 4 GB of memory, any storage system setup and with no restrictions on database size or any other artificial restrictions.

anonymous
()
Ответ на: комментарий от anonymous

>Только типовые конфигурации 1С используют в PostgreSQL табличные блокировки, что большинству заказчиков не подходит.

То понос (патчить надо), то золотуха.

Sun-ch
()
Ответ на: комментарий от Sun-ch

> То понос (патчить надо), то золотуха.

Use DB/2.

anonymous
()
Ответ на: комментарий от anonymous

> Когда позвонил в техподдержку, и спросил, как у них насчёт блокировок в типовых конфигурациях в случае с PostgreSQL, получил ответ, что если под виндой - ставь MSSQL, если под LINUX - DB2.

Как я понял все блокировки были заботливо перенесены для совместимости с MSSQL :)

IMHO техподдержки разные бывают - 1С это же не одна фирма - это "франчаза".

Evgueni ★★★★★
()
Ответ на: комментарий от Evgueni

> Как я понял все блокировки были заботливо перенесены для совместимости с MSSQL

Если бы! В MSSQL у 1сv8 блокировки на уровне записей, а поскольку PGSQL - версионник, а не блокировочник, то для 1с оказалось слишком сложно полностью эмулировать блокировки на версионнике.. вот и сделали тупо - блокируется таблица целиком. Это сильно не рулез с т.з. одновременной работы.. Так что pgsql в 1с - для десятка пользователей, не больше.. так сказать, промежуточная ниша между файловым вариантом и mssql/db2.

Annymous
()
Ответ на: комментарий от Annymous

IMHO это я и имел в виду - ну не работают обычно с PostgreSQL с _таким_ количеством блокировок - другая немного логика нужна. Я думаю, что со временем это поменяется ибо у версионика в ДНК всё же получше блокировочника.

Evgueni ★★★★★
()

А как там опять насчет русского языка в новостях (см. мой заголовок поста)???!!!

orlusha
()
Ответ на: комментарий от Evgueni

> Я думаю, что со временем это поменяется ибо у версионика в ДНК всё же получше блокировочника.

Вот только доживем ли мы ...

anonymous
()
Ответ на: комментарий от Annymous

>Если бы! В MSSQL у 1сv8 блокировки на уровне записей, а поскольку PGSQL - версионник, а не блокировочник, то для 1с оказалось слишком сложно полностью эмулировать блокировки на версионнике.. вот и сделали тупо - блокируется таблица целиком. Это сильно не рулез с т.з. одновременной работы.. Так что pgsql в 1с - для десятка пользователей, не больше.. так сказать, промежуточная ниша между файловым вариантом и mssql/db2.

Т.е. почитать документацию к PostgreSQL в 1С ниасилили.

"Chapter 12. Concurrency Control

12.3.2. Row-Level Locks

In addition to table-level locks, there are row-level locks, which can be exclusive or shared locks. An exclusive row-level lock on a specific row is automatically acquired when the row is updated or deleted. The lock is held until the transaction commits or rolls back, in just the same way as for table-level locks. Row-level locks do not affect data querying; they block writers to the same row only.

To acquire an exclusive row-level lock on a row without actually modifying the row, select the row with SELECT FOR UPDATE. Note that once the row-level lock is acquired, the transaction may update the row multiple times without fear of conflicts.

To acquire a shared row-level lock on a row, select the row with SELECT FOR SHARE. A shared lock does not prevent other transactions from acquiring the same shared lock. However, no transaction is allowed to update, delete, or exclusively lock a row on which any other transaction holds a shared lock. Any attempt to do so will block until the shared lock(s) have been released.

PostgreSQL doesn't remember any information about modified rows in memory, so it has no limit to the number of rows locked at one time. However, locking a row may cause a disk write; thus, for example, SELECT FOR UPDATE will modify selected rows to mark them locked, and so will result in disk writes.

In addition to table and row locks, page-level share/exclusive locks are used to control read/write access to table pages in the shared buffer pool. These locks are released immediately after a row is fetched or updated. Application developers normally need not be concerned with page-level locks, but we mention them for completeness."

anonymous
()
Ответ на: комментарий от anonymous

> Т.е. почитать документацию к PostgreSQL в 1С ниасилили.

Ну конечно ... куда уж всяким лохам из 1С до ЛОРовским анонимоусов ...

FOR UPDATE/FOR SHARE ни коим образом не обеспечивает требуемый моделью разработки на 1С'овском языке уровень Serializable.

anonymous
()
Ответ на: комментарий от Sun-ch

> Я всегда был невысокого мнения о разработчиках из 1С, теперь это мнение только укрепилось.

Что способствовало укреплению?

anonymous
()

тем у кого 1С 8.1 с PgSQL, лучше скажите у всех по дикому тормозит расчёт з/п, или это только наше локальное горе от ума ?

MKuznetsov ★★★★★
()

> 21 сентября в Москве 4-часовой семинар по производительности PostgreSQL.

На сайте информации нет - сколько стоит участие в нем ? Я бы сездил в столицу так как озабочен этим вопросом сильно!

neDBA
()
Ответ на: комментарий от MKuznetsov

> тем у кого 1С 8.1 с PgSQL, лучше скажите у всех по дикому тормозит расчёт з/п, или это только наше локальное горе от ума ?

Я совершенно не спец в 1С - но по отзывам расчёт з/п замечательно тормозит и без PostgreSQL.

Evgueni ★★★★★
()
Ответ на: комментарий от Evgueni

Ну, в версии 8.1.8 они провели серьезную оптимизацию - потребление памяти сократилось в 2 раза, быстродействие возросло на столько же :)

anonymous
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.