The OpenNET Project / Index page

[ новости /+++ | форум | wiki | теги | ]

Для PostgreSQL предложено новое хранилище zheap

06.03.2018 23:10

Разработчики из компании EnterpriseDB представили новое хранилище zheap, которое предложено для включения в состав СУБД PostgreSQL 12. Хранилище zheap разработано для решения проблемы с разрастанием файлов с содержимым БД в результате фрагментации при обновлении содержимого записей и отличается от традиционного хранилища тем, что минимизирует необходимость выполнения операции VACUUM.

Суть предложенного в zheap формата хранения данных на диске в сохранении в основном хранилище только актуальных данных и выноса старых версий записей в отдельный лог отката изменений. При выполнении операций обновления записей данные в основном хранилище заменяются по месту, без применения схемы copy-on-write. Блоки, освобождающиеся в результате операций удаления или выполнения транзакции, для которых невозможна замена данных по месту, могут оперативно повторно использоваться сразу после высвобождения. Подобные особенности позволяют улучшить контроль за разрастанием хранилища и сделать его более предсказуемым.

Новое хранилище также позволяет добиться увеличения производительности и сократить размер служебных данных. Увеличение производительности достигается благодаря сокращению операций записи, путём исключения перезаписи страниц и выборочного обновления только индексированных столбцов без обновления каждого индекса. Оптимизация размера обеспечивается благодаря сокращению размера блоков (сокращён заголовок и исключено добавочное заполнение для выравнивания блока).

Тестирование производительности показало общее увеличение производительности, сокращение размера хранилища и более эффективное выполнение операций отката изменений. Наибольший выигрыш в производительности (до 45%) достигается в условиях большого числа операций перезаписи, а также когда операция UPDATE приводит к обновлению небольшого числа проиндексированных столбцов. Применение zheap также позволяет избавиться от проседания производительности во время активации процесса autovacuum и сократить число операций записи в WAL-лог. Из недостатков zheap упоминается более ресурсоёмкое выполнение операций удаления и сброса транзакций, а также снижение производительности при выполнении обновлений, затрагивающих большую часть проиндексированных столбцов.



  1. Главная ссылка к новости (http://amitkapila16.blogspot.r...)
  2. OpenNews: Релиз СУБД PostgreSQL 10
  3. OpenNews: Открыты исходные тексты СУБД CitusDB
  4. OpenNews: LinkedIn открыл код распределённого OLAP-хранилища Pinot
  5. OpenNews: Linux Foundation представил Kinetic, подключаемые через Ethernet самодостаточные хранилища
  6. OpenNews: В MySQL 8.0 отмечается закат хранилища MyISAM
Лицензия: CC BY 3.0
Короткая ссылка: https://opennet.ru/48214-postgresql
Ключевые слова: postgresql, zheap
При перепечатке указание ссылки на opennet.ru обязательно


Обсуждение (60) Ajax | 1 уровень | Линейный | +/- | Раскрыть всё | RSS
  • 1.1, никто (??), 23:39, 06/03/2018 [ответить] [﹢﹢﹢] [ · · · ]  
  • +2 +/
    Это же как у ORALCE c его роллбасл сегментом .... старое они оставят ?
     
     
  • 2.4, Аноним (-), 05:39, 07/03/2018 [^] [^^] [^^^] [ответить]  
  • +1 +/
    > Это же как у ORALCE c его роллбасл сегментом .... старое они оставят ?

    We have provided a storage engine option which you can set when creating a table. For example:
    create table t_zheap(c1 int, c2 varchar) with (storage_engine='zheap');

     
     
  • 3.12, Аноним (-), 08:55, 07/03/2018 [^] [^^] [^^^] [ответить]  
  • +6 +/
    Начинается свистопляска аля MySQL.
     
     
  • 4.27, rshadow (ok), 14:50, 07/03/2018 [^] [^^] [^^^] [ответить]  
  • +/
    Дык это с незапамятных времен было. Просто всех устраивает дефолтовый. Я думаю если бы в мускуле innodb был бы изначально по умолчанию, то myisam может и не вспомнил бы никто.
     
     
  • 5.29, angra (ok), 16:43, 07/03/2018 [^] [^^] [^^^] [ответить]  
  • +/
    У myisam полнотекстовый поиск и быстрые insert/update в наиболее частом варианте использования. innodb было как минимум с четвертого мускула, но в те времена единственным его преимуществом были внешние ключи, которые большей части пыхеров были ненужны, так что myisam был предпочтительным вариантом вовсе не из-за использования в качестве дефолта.

     
     
  • 6.36, Аноним (-), 18:04, 07/03/2018 [^] [^^] [^^^] [ответить]  
  • +1 +/
    > У myisam полнотекстовый поиск и быстрые insert/update в наиболее частом варианте использования.
    > innodb было как минимум с четвертого мускула, но в те времена
    > единственным его преимуществом были внешние ключи, которые большей части пыхеров были
    > ненужны, так что myisam был предпочтительным вариантом вовсе не из-за использования
    > в качестве дефолта.

    Была другая более фундаментальная причина. Пыхеры обычно обилием мозгов не отличаются, вернее -- отличаются их отсутствием. Поэтому понять недостатки myisam не могли в принципе. А чем меньше знаешь, тем лучше пища уваривается.

     
     
  • 7.46, angra (ok), 20:21, 07/03/2018 [^] [^^] [^^^] [ответить]  
  • +/
    Но ты то не такой, ты ведь понял недостатки MyISAM для тех задач. Так поведай о них, блесни интеллектом.
     
     
  • 8.49, YetAnotherOnanym (ok), 21:59, 07/03/2018 [^] [^^] [^^^] [ответить]  
  • +/
    Не знаю, как сейчас, а когда я имел дело с этим censored , myisam при записи ло... текст свёрнут, показать
     
  • 6.47, KonstantinB (ok), 20:30, 07/03/2018 [^] [^^] [^^^] [ответить]  
  • +/
    innodb был как минимум с 3.23,  и его преимуществом было всегда прежде всего то, что:
    1) это честный версионник,
    2) он написан не Монти сотоварищи, которые в то время слабо себе представляли, что такое ACID, а людьми, которые отлично понимают принципы разработки СУБД.
     
  • 6.53, Аноним (-), 05:59, 08/03/2018 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Регулярно вылавливаю последствия сладкой групповушки из MySQL(MyISAM)+PHP(Joomla)+ПыхПыхбибизьяна. Когда таблица логов разрастается до пары млн. строк, сайт начинает дико тупить, мыскль дико шуршит диском, запросам вечный лок. Горчишник в виде перегонки таблиц в InnoDB помогает.
     
  • 6.71, XoRe (ok), 18:54, 13/03/2018 [^] [^^] [^^^] [ответить]  
  • +/
    > но в те времена единственным его преимуществом были внешние ключи

    Не единственным и не главным.
    Главное преимущество innodb - поддержка транзакций (которой до сих пор нет у MyISAM).
    Т.е. ничего, серьезнее личного бложика, на MyISAM лучше не делать.
    А ведь много у кого на mysql завязаны деньги клиентов...

     
  • 4.48, KonstantinB (ok), 20:37, 07/03/2018 [^] [^^] [^^^] [ответить]  
  • +/
    > Начинается свистопляска аля MySQL.

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

     

  • 1.3, Аноним (-), 05:37, 07/03/2018 [ответить] [﹢﹢﹢] [ · · · ]  
  • –1 +/
    ураааа, мы победили vacuum, vacuum больше ненужно!
    Опять...

     
     
  • 2.5, Аноним (-), 05:41, 07/03/2018 [^] [^^] [^^^] [ответить]  
  • +1 +/
    > ураааа, мы победили vacuum, vacuum больше ненужно!
    > Опять...

    Ну при наличии undo/rollback - действительно не нужно, нужно только purge

    Vacuum/Autovacuum: We think that for delete-marked indexes we might not need vacuum, but we still need it for indexes that doesn't support delete-marking. Here, the idea is that by using undo technology we can change three-pass-vacuum to two-pass-vacuum. Currently any attempt to vacuum zheap will return error.

     
     
  • 3.11, Аноним (-), 08:45, 07/03/2018 [^] [^^] [^^^] [ответить]  
  • +1 +/
    там ключевое слово - "опять" ;-)

    > Currently any attempt to vacuum zheap will return error.

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

    ну, ладно, понятно что оно еще толком не родилось, подождем еще годик, вдруг чудо все же произойдет...  

     
     
  • 4.57, Аноним (-), 15:00, 08/03/2018 [^] [^^] [^^^] [ответить]  
  • +/
    Плюсую. Однако надо помнить, что по ходу этот zheap добавляет лишние операции записи в оперативном периоде, тогда как vacuum и делается отложено и при ненадобности можно его выключить.
     

  • 1.6, Это я (?), 05:49, 07/03/2018 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    На тот случай, если не у всех есть fullflash схд - можно ли указать путь, где создавать/хранить индексы? Чтобы не приходилось их переносить вручную.
     
     
  • 2.40, Аноним (-), 18:14, 07/03/2018 [^] [^^] [^^^] [ответить]  
  • +/
    > На тот случай, если не у всех есть fullflash схд - можно
    > ли указать путь, где создавать/хранить индексы? Чтобы не приходилось их переносить
    > вручную.

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

     

  • 1.10, Аноним (-), 08:38, 07/03/2018 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    ZSTD сжатия до сих порт нет, inmemory таблиц до сих пор тоже нет. А обещали...
     
     
  • 2.35, Аноним (-), 18:00, 07/03/2018 [^] [^^] [^^^] [ответить]  
  • +3 +/
    > ZSTD сжатия до сих порт нет, inmemory таблиц до сих пор тоже
    > нет. А обещали...

    Зачем вот это вот inmemory? Вы хоть немного себе представляете как типичная современная СУБД работает, а? Ну вот если честно? Во всех современных СУБД ВСЯ ОБРАБОТКА и так inmemory, и по другому не бывает. Какое ещё inmemory вам нужно? Всякие неофиты крикливые выдумают очередной деревянный велосипед и давай радоваться тому, что уже лет 30-ть как повсеместно просто используется.

     

  • 1.15, лютый жабист__ (?), 10:56, 07/03/2018 [ответить] [﹢﹢﹢] [ · · · ]  
  • –10 +/
    Самое смешное, что для 90% проектов MVCC не нужно. Ну ваще не нужно. Никуда и никак.

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

     
     
  • 2.17, amonymous (?), 10:58, 07/03/2018 [^] [^^] [^^^] [ответить]  
  • +5 +/
    Строите проекты без consistency? Ну удачи, чо.
     
     
  • 3.19, Аноним (-), 11:49, 07/03/2018 [^] [^^] [^^^] [ответить]  
  • –5 +/
    Фактически так жестко нужно наверно лишь в 10% случаев. Упрямые бараны, делают проблему из ничего. Ну пускай дальше землю бодают, есть куча альтернатив...
     
     
  • 4.42, _ (??), 18:27, 07/03/2018 [^] [^^] [^^^] [ответить]  
  • +2 +/
    >есть куча альтернатив...

    Это - да! Иди в садовники :)

     
  • 3.22, лютый жабист__ (?), 13:19, 07/03/2018 [^] [^^] [^^^] [ответить]  
  • –3 +/
    Выбрал ненужный в 90% случаев  C и отказался от нужного в 90% случаях А

    Ссзб чо

     
     
  • 4.43, _ (??), 18:28, 07/03/2018 [^] [^^] [^^^] [ответить]  
  • +/
    Это только у жабистов или-или. У нормальных людей - и то, и другое :-р
     
     
  • 5.54, лютый жабист__ (?), 12:37, 08/03/2018 [^] [^^] [^^^] [ответить]  
  • +/
    Местные "банкиры локалхоста" отменили теорему cap. Не сомневался
     
     
  • 6.60, _ (??), 17:15, 08/03/2018 [^] [^^] [^^^] [ответить]  
  • +/
    У нас частый случай, который покрывает 146% приложений, работающих с баблом.
    А пиписки на заборе ... да хоть монгай рисуй :)
     
  • 2.20, Аноним (-), 12:00, 07/03/2018 [^] [^^] [^^^] [ответить]  
  • +17 +/
    >Самое смешное, что для 90% проектов MVCC не нужно. Ну ваще не нужно. Никуда и никак.

    Из серии "Самые тупые фразы в ИТ. Золотое издание" из разряда:
    * 90% времени отазоустойчивость не нужна
    * 90% времени бэкап не нужен
    * 90% проектов хватит одной базы данных на одном сервере у одного провайдера.

    Думаете, почему только 10% проектов успешны? Да потому что 90% обслуживают кретины.

     
     
  • 3.23, лютый жабист__ (?), 13:33, 07/03/2018 [^] [^^] [^^^] [ответить]  
  • –2 +/
    >из разряда:
    > * 90% времени отазоустойчивость не нужна

    Экспедры опеннета считают, постгрес в теореме о САР весь такой распупырчатый сразу всё умеет :) это ваше mvcc и бэкапы делать нормально не даёт, а только мееедленно и печально

     
     
  • 4.28, rshadow (ok), 15:02, 07/03/2018 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Дык дело не в mvcc. Просто в постгре очень много чего не доделано в плане обслуживания самой БД. Даже вот миграция на новую версию без простоя можно делать только в 10-ке (логическая репликация). По факту для репликаций, бекапов пока только бубнами и сторонними проектами можно пользоваться.
    Но все же караван идет...
     
     
  • 5.33, Аноним (-), 17:54, 07/03/2018 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Я не знаю ни одной СУБД, где миграция на новую версию ПО файлов данных прежней происходит бесшовно.
     
     
  • 6.41, лютый жабист__ (?), 18:26, 07/03/2018 [^] [^^] [^^^] [ответить]  
  • –5 +/
    > не знаю ни одной СУБД, где миграция на новую версию ПО файлов данных прежней происходит бесшовно.

    Подрастёшь, узнаешь

     
     
  • 7.51, Кузнец (?), 23:22, 07/03/2018 [^] [^^] [^^^] [ответить]  
  • +/
    >> не знаю ни одной СУБД, где миграция на новую версию ПО файлов данных прежней происходит бесшовно.
    > Подрастёшь, узнаешь

    Подрасту я уже вряд ли. Давайте лучше примеры. В Оракле переход с версии на версию редкий гемор. В Сиквеле -- не лучше. В сибасе не лучше. В ДБ2 там полная изотерика. Что ещё предложите?

     
     
  • 8.55, лютый жабист__ (?), 12:45, 08/03/2018 [^] [^^] [^^^] [ответить]  
  • +/
    В орацле вообще всё - жуткий гемор А то кто ж курсы купит Тут интересно, Монго... текст свёрнут, показать
     
     
  • 9.59, Кузнец (?), 16:46, 08/03/2018 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Оракл отлично документирован Причём его освоение дёшево и доступно Слон в этом... текст свёрнут, показать
     
     
  • 10.63, лютый жабист__ (?), 19:55, 08/03/2018 [^] [^^] [^^^] [ответить]  
  • +/
    п1 А на нашей планете все курсы по Оракле от полтинника-сотни, даже самые плеши... текст свёрнут, показать
     
     
  • 11.64, Кузнец (?), 21:58, 08/03/2018 [^] [^^] [^^^] [ответить]  
  • +/
    По-моему, курсы по Ораклу совершенно бесполезны У Оракла отличная публичная бес... текст свёрнут, показать
     
     
  • 12.65, нах (?), 05:33, 09/03/2018 [^] [^^] [^^^] [ответить]  
  • +/
    курсы-то полезны, просто они не для вас в основном - во всяком случае, все эти ... текст свёрнут, показать
     
  • 12.67, лютый жабист__ (?), 20:12, 09/03/2018 [^] [^^] [^^^] [ответить]  
  • +/
    Как могут быть отличной документацией талмуды на 100500 страниц про то, что само... текст свёрнут, показать
     
     
  • 13.68, Кузнец (?), 13:50, 10/03/2018 [^] [^^] [^^^] [ответить]  
  • +/
    Ну тут уж кому и на горшок сходить самому или шнурки завязать -- мегаусложнённый... текст свёрнут, показать
     
  • 9.61, _ (??), 17:23, 08/03/2018 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Ну ужос, да Но не УЖОС-УЖОС же Ваши жабьи ЕЕ иной раз позаковыристее любо... текст свёрнут, показать
     
  • 5.34, Аноним (-), 17:57, 07/03/2018 [^] [^^] [^^^] [ответить]  
  • +2 +/
    > Дык дело не в mvcc. Просто в постгре очень много чего не
    > доделано в плане обслуживания самой БД. Даже вот миграция на новую
    > версию без простоя можно делать только в 10-ке (логическая репликация). По
    > факту для репликаций, бекапов пока только бубнами и сторонними проектами можно
    > пользоваться.
    > Но все же караван идет...

    Но ведь это и близко не так. И репликация, и, тем более, резервное копирование в Слоне никакой проблемы не представляет. Всё, в общем-то, как и у других. Единственно, из общей массы Оракл со своим крайне удобным RMAN-ом выделяется, ну так Оракл и стоит куда дороже, чем любые коммерческие решения резервного копирования для Слона (или, скажем, для Сиквел сервака).

     
     
  • 6.45, Moomintroll (ok), 18:30, 07/03/2018 [^] [^^] [^^^] [ответить]  
  • +/
    > Оракл со своим крайне удобным RMAN-ом

    Да ладно! Вы действительно считаете RMAN удобным?

    Функциональный - соглашусь.

     
     
  • 7.50, Кузнец (?), 23:20, 07/03/2018 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Субъективно, конечно же, но по мне это лучшее решение. Обширная функциональность, хорошая документация, отличные возможности скриптинга, понятная модель.
     
  • 4.39, Аноним (-), 18:09, 07/03/2018 [^] [^^] [^^^] [ответить]  
  • +1 +/
    >>из разряда:
    >> * 90% времени отазоустойчивость не нужна
    > Экспедры опеннета считают, постгрес в теореме о САР весь такой распупырчатый сразу
    > всё умеет :) это ваше mvcc и бэкапы делать нормально не
    > даёт, а только мееедленно и печально

    Чувак, как бэкапы связаны с реализацией mvcc в Слоне? Ты вообще хоть немного понимаешь о чём пишешь?

     
  • 2.37, Аноним (-), 18:06, 07/03/2018 [^] [^^] [^^^] [ответить]  
  • +3 +/
    > Самое смешное, что для 90% проектов MVCC не нужно. Ну ваще не
    > нужно. Никуда и никак.
    > Вместо того, чтобы отломать транзакции, героически борются с их следствиями уже почти
    > 20 лет...

    Зачем тогда СУБД вообще? В файлик пишите всё подряд. К чему эта морока?

     
     
  • 3.56, лютый жабист__ (?), 12:47, 08/03/2018 [^] [^^] [^^^] [ответить]  
  • +/

    > Зачем тогда СУБД вообще? В файлик пишите всё подряд.

    Изобрёл носкль? Увы, это сделали ещё 10 лет назад. И оно уже лет 5 как вытеснило рсубд

     
     
  • 4.58, Кузнец (?), 16:39, 08/03/2018 [^] [^^] [^^^] [ответить]  
  • +/
    Понимаете, нет никакого носкуль. Носкуль == имплицитный скуль. Т.е. вы пихаете кучу плоских данных, а затем, чаще всего крайне убогий индийский анализатор, сам за вас лепит кривую, но всю так же рэшэнал-модель. Причём делает это динамически и с непредсказуемой стабильностью результата. Сейчас нет даже на академ. уровне проработанной замены реляционной модели. А если нет модели на академ. уровне, т.е. там, где люди хоть немного отвечают за свои слова репутацией и их заявления хоть кто-то верифицирует, я таким пользоваться не стану. Поэтому пока Носкуль это секта верующих.
     
  • 4.62, _ (??), 19:06, 08/03/2018 [^] [^^] [^^^] [ответить]  
  • +/
    >Изобрёл носкль? Увы, это сделали ещё 10 лет назад.

    Му-ха-ха! До чего же жабщики на всю голову волшебные! :-))))
    Это 10 лет назад начали __называть__ NoSQL. Ну куда же хипсторам без хайпа :)
    А так (тряся сединой на ЖЖ :) помницо в IBM/360 key-value (hashed keys) _уже_ было. И его даже COBOL-щики юзают, не то что жаберы :-)
    >И оно уже лет 5 как вытеснило рсубд

    В голове отдельного индивида и не такие майданы могут происходить :) На реальный мир это никак не влияет.

     
     
  • 5.66, люьый жабист__ (?), 20:04, 09/03/2018 [^] [^^] [^^^] [ответить]  
  • +/
    key-value Это не субд.
     

  • 1.18, Аноним (-), 11:34, 07/03/2018 [ответить] [﹢﹢﹢] [ · · · ]  
  • –1 +/
    > Суть предложенного в zheap формата хранения данных на диске в сохранении в основном хранилище только актуальных данных и выноса старых версий записей в отдельный лог отката изменений

    Я не совсем понял, они этакую VCS в СУБД придумали?

     
     
  • 2.24, аноним 12 (?), 14:15, 07/03/2018 [^] [^^] [^^^] [ответить]  
  • +/
    Какие такие «они»? Сегмент наката так и хранится, просто они сделали ещё и сегмент отката.
     
     
  • 3.31, Аноним (-), 16:51, 07/03/2018 [^] [^^] [^^^] [ответить]  
  • +/
    > Какие такие «они»? Сегмент наката так и хранится, просто они сделали ещё
    > и сегмент отката.

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

     
     
  • 4.38, Аноним (-), 18:06, 07/03/2018 [^] [^^] [^^^] [ответить]  
  • +/
    >> Какие такие «они»? Сегмент наката так и хранится, просто они сделали ещё
    >> и сегмент отката.
    > )))))
    > Исторические данные в Слоне традиционно хранились вместе

    ... вместе с актуальными...


     
  • 2.30, Аноним (-), 16:47, 07/03/2018 [^] [^^] [^^^] [ответить]  
  • +/
    MVCC. Нет, не слышал?
     

  • 1.26, Аноним (-), 14:49, 07/03/2018 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Сделали таки сегменты отката. Не очень нужно, в общем-то.
    Нормально настроенные autovacuum удобней, чем возьня с контролем за местом ещё и под сегменты отката.
     
  • 1.52, Кузнец (?), 23:29, 07/03/2018 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    В Слоне же единственной проблемой реализации MVCC были короткие 32-битные XID-ы. Ну так эту проблему вынос исторических данных в отдельный хип не решает ни в какой мере. Да и проблемой это сложно назвать, если честно. В общем, не знаю: по-моему, Слон 9.2 был и так, в плане концепции, вполне достаточен. Дальше уже пошли куда-то... вширь.
     
  • 1.69, DeadMustdie (??), 14:36, 12/03/2018 [ответить] [﹢﹢﹢] [ · · · ]  
  • –1 +/
    > выноса старых версий записей в отдельный лог отката изменений

    О да, они сделали UNDO aka ROLLBACK SEGMENT

    > исключения перезаписи страниц

    И похоже, добавили буферные пулы.

    Интересно, почему сие произошло только сейчас? :)

     
     
  • 2.70, Andrey Mitrofanov (?), 16:18, 12/03/2018 [^] [^^] [^^^] [ответить]  
  • +/
    > Интересно, почему сие произошло только сейчас? :)

    Почему сейчас? Так ентропия легла.

    Манагеры ентерпрайсдебе прочитали wikipedia://MVCC и запилили в свой сейлз-буклетик к|/|ллер-фичу "как в оракле".

     

     Добавить комментарий
    Имя:
    E-Mail:
    Текст:



    Партнёры:
    PostgresPro
    Inferno Solutions
    Hosting by Hoster.ru
    Хостинг:

    Закладки на сайте
    Проследить за страницей
    Created 1996-2024 by Maxim Chirkov
    Добавить, Поддержать, Вебмастеру