The OpenNET Project / Index page

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

форумы  помощь  поиск  регистрация  майллист  вход/выход  слежка  RSS
"Для PostgreSQL развиваются механизмы ускорения за счёт привл..."
Вариант для распечатки  
Пред. тема | След. тема 
Форум Разговоры, обсуждение новостей
Изначальное сообщение [ Отслеживать ]

"Для PostgreSQL развиваются механизмы ускорения за счёт привл..."  +/
Сообщение от opennews (ok) on 23-Дек-14, 23:10 
В рамках проекта PG-Storm (https://github.com/pg-strom) при участии компании NEC развивается дополнение к СУБД PostgreSQL, позволяющее вынести на плечи GPU выполнение некоторых операций обработки SQL-запроса. В частности, за счёт  привлечения GPU могут быть ускорены такие операции как сравнительный перебор элементов таблиц, агрегирование записей и слияние хэшей.
<center><img src="http://www.opennet.dev/opennews/pics_base/0_1419364747.png" style="border-style: solid; border-color: #e9ead6; border-width: 15px;max-width:100%;" title="" border=0></center>

Код для выполнения на стороне GPU генерируется в момент разбора SQL-запроса при помощи специального JIT-компилятора и в дальнейшем выполняется параллельно с другими связанными с текущим запросом операциями, выполняемыми на CPU. Для выполнения заданий на GPU задействован OpenCL. Из присутствующих на данной стадии развития проекта ограничений отмечается возможность использования GPU только для данных, хранимых в оперативной памяти. Увеличение производительности операций слияния таких таблиц при использовании GPU увеличивается в десятки раз.
<center><img src="http://www.opennet.dev/opennews/pics_base/0_1419364684.png" style="border-style: solid; border-color: #606060; border-width: 1px;max-width:100%;" title="" border=0></center>


<center><img src="http://www.opennet.dev/opennews/pics_base/0_1419364872.png" style="border-style: solid; border-color: #e9ead6; border-width: 15px;max-width:100%;" title="" border=0></center>
<center><img src="http://www.opennet.dev/opennews/pics_base/0_1419364956.png" style="border-style: solid; border-color: #e9ead6; border-width: 15px;max-width:100%;" title="" border=0></center>


<center>
<iframe src="//www.slideshare.net/slideshow/embed_code/42903351" width="425" height="355" frameborder="0" marginwidth="0" marginheight="0" scrolling="no" style="border:1px solid #CCC; border-width:1px; margin-bottom:5px; max-width: 100%;" allowfullscreen> </iframe></center>

URL: https://news.ycombinator.com/item?id=8787414
Новость: http://www.opennet.dev/opennews/art.shtml?num=41333

Ответить | Правка | Cообщить модератору

Оглавление

Сообщения по теме [Сортировка по времени | RSS]


1. "Для PostgreSQL развиваются механизмы ускорения за счёт привл..."  +45 +/
Сообщение от A.Stahl (ok) on 23-Дек-14, 23:10 
Это заговор бородатых свитероносцев: скоро выйдет Half-Life3 и свитероносцы хотят иметь внятное обоснование хорошим видеокартам в серверной.
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

7. "Для PostgreSQL развиваются механизмы ускорения за счёт привл..."  +6 +/
Сообщение от Another one Аноним on 24-Дек-14, 00:32 
...а хранить эту самую базу надо будет в видеопамяти видеокарты!
Ответить | Правка | ^ к родителю #1 | Наверх | Cообщить модератору

11. "Для PostgreSQL развиваются механизмы ускорения за счёт привл..."  +2 +/
Сообщение от Аноним (??) on 24-Дек-14, 01:41 
Теперь DBA прокачают свои скиллы в сетевых шутерах.
Ответить | Правка | ^ к родителю #1 | Наверх | Cообщить модератору

2. "Для PostgreSQL развиваются механизмы ускорения за счёт привл..."  +1 +/
Сообщение от rob pike on 23-Дек-14, 23:17 
На тему параллелизма тоже есть несколько интересных попыток
http://rhaas.blogspot.ru/2014/12/parallelism-update.html
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

5. "Для PostgreSQL развиваются механизмы ускорения за счёт привл..."  +/
Сообщение от Crazy Alex (ok) on 24-Дек-14, 00:02 
Хм, фраза насчёт "данных в памяти" намекает, что такая штука больше подошла бы всяким NoSQL, который ох как любят в памяти всё подряд хранить...
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

6. "Для PostgreSQL развиваются механизмы ускорения за счёт привл..."  +1 +/
Сообщение от Аноним (??) on 24-Дек-14, 00:31 
попробуй постгресу в конфиге памяти добавить, увидишь, как он память любит
Ответить | Правка | ^ к родителю #5 | Наверх | Cообщить модератору

8. "Для PostgreSQL развиваются механизмы ускорения за счёт привл..."  +3 +/
Сообщение от XoRe (ok) on 24-Дек-14, 01:19 
> Хм, фраза насчёт "данных в памяти" намекает, что такая штука больше подошла
> бы всяким NoSQL, который ох как любят в памяти всё подряд
> хранить...

Если postgres не использует всю оперативку, до которой может дотянуться, значит что-то в настройках не так.
Но идея с nosql интересная.
Это больше подойдет многопоточному memcache, чем однопоточному redis.
Правда, это ещё надо постараться нагрузить memcache так, чтобы возникла нужда в ускорении.
У pgsql нашли узкое место, которое можно ускорить.
С memcache так может не получиться.

Ответить | Правка | ^ к родителю #5 | Наверх | Cообщить модератору

10. "Для PostgreSQL развиваются механизмы ускорения за счёт привл..."  –6 +/
Сообщение от pavlinux (ok) on 24-Дек-14, 01:40 
> Это больше подойдет многопоточному memcache, чем однопоточному redis.

Напомни, сколько на PCI-Express контактов?

Ответить | Правка | ^ к родителю #8 | Наверх | Cообщить модератору

54. "Для PostgreSQL развиваются механизмы ускорения за счёт привл..."  +/
Сообщение от XoRe (ok) on 05-Янв-15, 21:16 
>> Это больше подойдет многопоточному memcache, чем однопоточному redis.
> Напомни, сколько на PCI-Express контактов?

Ну что же вы, уважаемый, никогда в редис не упирались?

https://code.google.com/p/memcached/wiki/NewConfiguringServe...

redis:
It does not use pipelining or any parallelism at all (one pending query per connection at most, and no multi-threading).
http://redis.io/topics/benchmarks

Ответить | Правка | ^ к родителю #10 | Наверх | Cообщить модератору

32. "Для PostgreSQL развиваются механизмы ускорения за счёт привл..."  +/
Сообщение от Crazy Alex (ok) on 24-Дек-14, 12:56 
Не, я о другом. И я имел в виду не мемкеш, в котором,  в общем-то, тоже только индексы считать, и даже не редис. А скорее что-то вроде mongo/couch, где, во-первых, map/reduce (т.е. хороший параллелизм гарантирован), во-вторых - документный формат, в котором можно всякие агрегаты считать для каждого документа, в-третьих - при нужде можно довольно спокойно пол-языка поломать под хорошую оптимизацию, и пользователи это проглотят.
Ответить | Правка | ^ к родителю #8 | Наверх | Cообщить модератору

35. "Для PostgreSQL развиваются механизмы ускорения за счёт привл..."  +/
Сообщение от Аноним (??) on 24-Дек-14, 13:21 
PostgreSQL откушивает ровно столько, сколько задал в shared_buffers.
Ответить | Правка | ^ к родителю #8 | Наверх | Cообщить модератору

37. "Для PostgreSQL развиваются механизмы ускорения за счёт привл..."  +/
Сообщение от Andrey Mitrofanov on 24-Дек-14, 13:33 
> PostgreSQL откушивает ровно столько, сколько задал в shared_buffers.

Кеш и буферы ядра ещё посчитай, сразу не "ровно" станет.

Ответить | Правка | ^ к родителю #35 | Наверх | Cообщить модератору

44. "Для PostgreSQL развиваются механизмы ускорения за счёт привл..."  +/
Сообщение от Аноним (??) on 25-Дек-14, 02:46 
не, это по-другому работает.
95% workload-а современных SQL БД - ворочается на тамошних UDF, которые ничем от байт-кода жабы или .Net отличаются в этом плане.
и в случае возможности хотя бы мизерно все это дело ускорить и/или распаралелить, профит фантастический.
те кто юзает не вполне SQL-compliant костыли вроде форков mysql и прочей хреновины, это дело не поддерживающих ССЗБ, конечно. но для остальных - профит весом, да.
Ответить | Правка | ^ к родителю #5 | Наверх | Cообщить модератору

9. "Для PostgreSQL развиваются механизмы ускорения за счёт привл..."  +/
Сообщение от Аноним (??) on 24-Дек-14, 01:38 
Ну вот, будущее наступило. Теперь базе данных будет требоваться видеокарта :).
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

13. "Для PostgreSQL развиваются механизмы ускорения за счёт привл..."  –1 +/
Сообщение от pavlinux (ok) on 24-Дек-14, 01:42 
> Ну вот, будущее наступило. Теперь базе данных будет требоваться видеокарта :).

Accelerating SQL Database Operations on a GPU with CUDA © 2010  
http://www.gpucomputing.net/sites/default/files/papers/408/b...

Ответить | Правка | ^ к родителю #9 | Наверх | Cообщить модератору

45. "Для PostgreSQL развиваются механизмы ускорения за счёт привл..."  +/
Сообщение от Аноним (??) on 25-Дек-14, 04:17 
> Accelerating SQL Database Operations on a GPU with CUDA © 2010

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

Ответить | Правка | ^ к родителю #13 | Наверх | Cообщить модератору

53. "Для PostgreSQL развиваются механизмы ускорения за счёт привл..."  +1 +/
Сообщение от pavlinux (ok) on 28-Дек-14, 00:07 
>> Accelerating SQL Database Operations on a GPU with CUDA © 2010
> Никто в здравом уме не будет лочить себя на апи от нвидии
> с единственной на планете реализацией в виде их проприетарного блоба. Пора
> бы это уже понять - психов готовых добровольно сунуться в этот
> медвежий капкан на планете немного.

Ононимные Оналитеги Опеннета рулят и пидалят! А TOP500 - просто сборище дебилов!

Ответить | Правка | ^ к родителю #45 | Наверх | Cообщить модератору

38. "Для PostgreSQL развиваются механизмы ускорения за счёт привл..."  –2 +/
Сообщение от Аноним (??) on 24-Дек-14, 18:43 
Где только они видели серверные платформы с боле-менее приличными видеокартами ... Самое большее - встроенные Intel или Matrox (чипы разработки 15-летней давности).
Ответить | Правка | ^ к родителю #9 | Наверх | Cообщить модератору

41. "Для PostgreSQL развиваются механизмы ускорения за счёт привл..."  +/
Сообщение от orgkhnargh (ok) on 24-Дек-14, 21:25 
http://www.nvidia.ru/object/nvidia-grid-ru.html
Ответить | Правка | ^ к родителю #38 | Наверх | Cообщить модератору

46. "Для PostgreSQL развиваются механизмы ускорения за счёт привл..."  +1 +/
Сообщение от Аноним (??) on 25-Дек-14, 04:18 
> Где только они видели серверные платформы с боле-менее приличными видеокартами ...

А вон в топ500 посмотри...

Ответить | Правка | ^ к родителю #38 | Наверх | Cообщить модератору

49. "Для PostgreSQL развиваются механизмы ускорения за счёт привл..."  +/
Сообщение от Аноним (??) on 27-Дек-14, 14:32 
Ещё такие есть:

http://www.intel.com/content/www/us/en/processors/xeon/xeon-...

http://blog.xcelerit.com/intel-xeon-phi-vs-nvidia-tesla-gpu/

Т.е. видеовыходов у этих "видеокарт" может и не быть

Ответить | Правка | ^ к родителю #38 | Наверх | Cообщить модератору

12. "Для PostgreSQL развиваются механизмы ускорения за счёт привл..."  +2 +/
Сообщение от Прохожий (??) on 24-Дек-14, 01:42 
OpenCL подойдет для любых задач, так или иначе, связанных с большими объемами вычислений.
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

15. "Для PostgreSQL развиваются механизмы ускорения за счёт привл..."  +/
Сообщение от Аноним (??) on 24-Дек-14, 03:39 
Но имеет смысл только на тех которые можно хорошо параллелизовать.
Ответить | Правка | ^ к родителю #12 | Наверх | Cообщить модератору

30. "Для PostgreSQL развиваются механизмы ускорения за счёт привл..."  +/
Сообщение от Аноним (??) on 24-Дек-14, 11:20 
OpenCL жрет энергию и все равно все упрется в I/O
Ответить | Правка | ^ к родителю #12 | Наверх | Cообщить модератору

14. "Для PostgreSQL развиваются механизмы ускорения за счёт привл..."  +/
Сообщение от Аноним (??) on 24-Дек-14, 02:03 
Давно пора.
> задействован OpenCL

Это правильно.

Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

19. "Для PostgreSQL развиваются механизмы ускорения за счёт привл..."  +/
Сообщение от bOOster email(ok) on 24-Дек-14, 05:32 
Нужное дело делают.
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

21. "Для PostgreSQL развиваются механизмы ускорения за счёт привл..."  +/
Сообщение от Аноним (??) on 24-Дек-14, 06:14 
Интересно, а их не смущает тот факт, что у большинства видеокарт динамическая память (GDDRx) не то что без ECC, а еще и допускает и bitflip'ы чаще обычной системной ОЗУ без ECC?
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

47. "Для PostgreSQL развиваются механизмы ускорения за счёт привл..."  +1 +/
Сообщение от Аноним (??) on 25-Дек-14, 04:21 
> Интересно, а их не смущает тот факт, что у большинства видеокарт динамическая
> память (GDDRx) не то что без ECC,

Вообще-то в профессиональных/серверных моделях видеокарт - вполне себе с ECC.

> а еще и допускает и bitflip'ы чаще обычной системной ОЗУ без ECC?

Так нефиг оверклокать и вольтажи за номинал выставлять. Ну и охлаждение нормальное должно быть (да, некоторые OEM-ы - те еще упыри, хотя ПЕЧи горячие сами по себе например). В том числе и в системнике (актуально для мощных GPU). Если все это соблюдено - нормальная видеокарта может работать годами без сбоев. Толпы майнеров уже проверили, потому что бабло побеждает зло :).

Ответить | Правка | ^ к родителю #21 | Наверх | Cообщить модератору

22. "Для PostgreSQL развиваются механизмы ускорения за счёт привл..."  +1 +/
Сообщение от Аноним (??) on 24-Дек-14, 07:46 
Для таких задачей есть firepro and tesla. у них память с ecc.
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

23. "Для PostgreSQL развиваются механизмы ускорения за счёт привл..."  +4 +/
Сообщение от _йцукен (ok) on 24-Дек-14, 08:23 
на серверах теперь будут игровые карточки ? =)
вечерком когда уже ни кому не уперлись скуль запросы можно порубиться в игрушки сисадминам ? =D

==
все таки не зря говорят что история развивается по спирали, вернулись в 198х с 286 процессорами и математическими сопроцессорами 287

Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

24. "Для PostgreSQL развиваются механизмы ускорения за счёт привл..."  +/
Сообщение от Xaionaro email(ok) on 24-Дек-14, 08:57 
> на серверах теперь будут игровые карточки ? =)

Игровые никуда не годятся. В тех же игровых nvidia CUDA чисто формальная. При попытке ускорить за счёт неё перемножение матриц получаешь только замедление.

Для использования GPU в таких целях нужно покупать специальные вычислительные GPU-шнки (наличие на которых output-интерфейсов для подключения мониторов далеко не обязательно [1]).

[1] http://www.3dnews.ru/assets/external/illustrations/2012/11/1...

> все таки не зря говорят что история развивается по спирали, вернулись в 198х с 286 процессорами и математическими сопроцессорами 287

Сколько лет мне промывают мозги этими GPU-шками, но лично меня всё равно больше привлекают CPU-шки с AVX-ами (и им подобными).

Ответить | Правка | ^ к родителю #23 | Наверх | Cообщить модератору

26. "Для PostgreSQL развиваются механизмы ускорения за счёт привл..."  +4 +/
Сообщение от Аноним (??) on 24-Дек-14, 09:51 
>Игровые никуда не годятся. В тех же игровых nvidia CUDA чисто формальная. При попытке ускорить за счёт неё перемножение матриц получаешь только замедление.

А пацаны из BOINC и не знали.

Ответить | Правка | ^ к родителю #24 | Наверх | Cообщить модератору

48. "Для PostgreSQL развиваются механизмы ускорения за счёт привл..."  +/
Сообщение от Аноним (??) on 25-Дек-14, 04:22 
> А пацаны из BOINC и не знали.

Авторы майнеров коинов и крякеров хэшей тоже как-то не в курсе :)

Ответить | Правка | ^ к родителю #26 | Наверх | Cообщить модератору

50. "Для PostgreSQL развиваются механизмы ускорения за счёт привл..."  +/
Сообщение от Xaionaro email(ok) on 27-Дек-14, 16:07 
>> А пацаны из BOINC и не знали.
> Авторы майнеров коинов и крякеров хэшей тоже как-то не в курсе :)

Mine-ите coin-ы на своей игровой видеокарте? Успешно?

Ответить | Правка | ^ к родителю #48 | Наверх | Cообщить модератору

51. "Для PostgreSQL развиваются механизмы ускорения за счёт привл..."  +/
Сообщение от Xaionaro email(ok) on 27-Дек-14, 16:10 
>>Игровые никуда не годятся. В тех же игровых nvidia CUDA чисто формальная. При попытке ускорить за счёт неё перемножение матриц получаешь только замедление.
> А пацаны из BOINC и не знали.

А можно конкретные ссылки? Я лично сам пробовал эту CUDA. Или может поделитесь собственным опытом?

Ответить | Правка | ^ к родителю #26 | Наверх | Cообщить модератору

33. "Для PostgreSQL развиваются механизмы ускорения за счёт привл..."  +/
Сообщение от Xasd (ok) on 24-Дек-14, 12:59 
всё правильно написал
Ответить | Правка | ^ к родителю #24 | Наверх | Cообщить модератору

34. "Для PostgreSQL развиваются механизмы ускорения за счёт привл..."  +1 +/
Сообщение от Crazy Alex (ok) on 24-Дек-14, 13:00 
Ну так NVidia - тот ещё махинатор. На вид там карты от AMD лучше пойдут - куча мелких вычислительных блоков.
Ответить | Правка | ^ к родителю #24 | Наверх | Cообщить модератору

43. "Для PostgreSQL развиваются механизмы ускорения за счёт привл..."  +/
Сообщение от Аноним (??) on 25-Дек-14, 01:12 
> Игровые никуда не годятся. В тех же игровых nvidia CUDA чисто формальная.

Выкинь маркетинговый булшит от нвидии из головы, чувак.

0) CUDA - проприетарное нечто от нвидии. А OpenCL - для всех, в отличие от. Он в том числе и нвидией реализуется.

1) У амд например игровые карточки в OpenCL долбят так что за ушами трещит. Мой восьмиядерник на массово параллелизуемых задачах ненавязчиво продувает видяхе В 20-30 РАЗ. Вот если алгоритм не параллелится - хилые и относительно низкочастотные ALUшки с слабым flow control - могут разочаровать. Это не general purpose проц и даже не собиралось им быть.

2) На самом деле все сильно зависит от задач. У нвидии меньше алушек но они более сложные. У амд их при прочих равных больше. Поэтому они ударно себя показывают на несколько разных задачах.

3) Если что, у амд профессиональные карты от обычных отличаются в основном всякой там ECC памятью да повышенным числом выходов на монитор. А дробилка там та же самая. Ну да, на игровую карту пожадничают память с ECC паять, геймерам не критично. На серверах это уже более критично (системную память с ECC там ведь ставят, в отличие от десктопников).

> но лично меня всё равно больше привлекают CPU-шки с AVX-ами (и им подобными).

Никакие AVX ни разу не заткнут за пояс пачку ALU где счет идет на тысячи простых SIMDобразных дробилок. В сумме эта конструкция втыкает системному процу в десятки раз, если алгоритм параллелится. Потому что оно за 1 такт воротит прорву работы на порядки превышающие все эти AVX в их самых радужных мечтах. И даже сравнительная низкочастотность (GPU как правило тактируют в районе 1ГГц) при ТАКОМ количестве ALU - не проблема.

Ответить | Правка | ^ к родителю #24 | Наверх | Cообщить модератору

52. "Для PostgreSQL развиваются механизмы ускорения за счёт привл..."  +/
Сообщение от Xaionaro email(ok) on 27-Дек-14, 16:23 
>> Игровые никуда не годятся. В тех же игровых nvidia CUDA чисто формальная.
> Выкинь маркетинговый булшит от нвидии из головы, чувак.
> 0) CUDA - проприетарное нечто от нвидии.

Согласен

> А OpenCL - для всех,
> в отличие от. Он в том числе и нвидией реализуется.

Но OpenCL пытается быть универсальным, из-за чего теряет в производительности.

> 1) У амд например игровые карточки в OpenCL долбят так что за
> ушами трещит. Мой восьмиядерник на массово параллелизуемых задачах ненавязчиво продувает
> видяхе В 20-30 РАЗ.

А вам не лень показать исходный код?

> Вот если алгоритм не параллелится - хилые
> и относительно низкочастотные ALUшки с слабым flow control - могут разочаровать.
> Это не general purpose проц и даже не собиралось им быть.

Я в качестве сферического эксперимента в вакууме делаю тупое перемножение матриц. Очень легко параллелизуемый алгоритм.

>> но лично меня всё равно больше привлекают CPU-шки с AVX-ами (и им подобными).
> Никакие AVX ни разу не заткнут за пояс пачку ALU где счет
> идет на тысячи простых SIMDобразных дробилок. В сумме эта конструкция втыкает
> системному процу в десятки раз, если алгоритм параллелится. Потому что оно
> за 1 такт воротит прорву работы на порядки превышающие все эти
> AVX в их самых радужных мечтах. И даже сравнительная низкочастотность (GPU
> как правило тактируют в районе 1ГГц) при ТАКОМ количестве ALU -
> не проблема.

Честно сказать, не изучал вопрос расчёта на AMD-шных карточках. Я лишь лично тестировал nvidia. Я конечно могу уже очень плохо помнить, ибо было сравнительно давно, но с учётом почти 4-кратного прироста на double-ах на AVX даже с учётом перегонки данных туда-сюда, я получил на i5 производительность для перемножения матриц во _много_ раз больше, чем на GeForce GTX 650 Ti. Притом размер матриц подбирался специально так, чтобы выжать наибольшую производительность на этой GPU-шке. Может, конечно, память играет со мной злую шутку.

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

Ответить | Правка | ^ к родителю #43 | Наверх | Cообщить модератору

39. "Для PostgreSQL развиваются механизмы ускорения за счёт привл..."  +/
Сообщение от Аноним (??) on 24-Дек-14, 18:45 
> на серверах теперь будут игровые карточки ? =)

Причем тут карточки, если серверы нормальные вообще без графики ставятся?


Ответить | Правка | ^ к родителю #23 | Наверх | Cообщить модератору

40. "Для PostgreSQL развиваются механизмы ускорения за счёт привл..."  +/
Сообщение от Аноним (??) on 24-Дек-14, 19:57 
помимо смайликов Вам еще показывать табличку "сарказм" ?

"Графический процессор (англ. graphics processing unit, GPU) — отдельное устройство персонального компьютера или игровой приставки, выполняющее графический рендеринг."

лопата, можно смеяться ;)

Ответить | Правка | ^ к родителю #39 | Наверх | Cообщить модератору

36. "Для PostgreSQL развиваются механизмы ускорения за счёт привл..."  +1 +/
Сообщение от softfire email on 24-Дек-14, 13:28 
Торт.Невероятно крутая штука.
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

42. "Для PostgreSQL развиваются механизмы ускорения за счёт привл..."  +/
Сообщение от Аноним (??) on 24-Дек-14, 23:12 
Опомнились.
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

Архив | Удалить

Рекомендовать для помещения в FAQ | Индекс форумов | Темы | Пред. тема | След. тема




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

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