форумы  помощь  поиск  регистрация  майллист  вход/выход  слежка

Вариант для распечатки		Пред. тема | След. тема
Форум Разговоры, обсуждение новостей
Изначальное сообщение		[ Отслеживать ]

"Для 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.me/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.me/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.me/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.me/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.me/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 (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 (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 (ok) on 27-Дек-14, 16:07
	>> А пацаны из BOINC и не знали. > Авторы майнеров коинов и крякеров хэшей тоже как-то не в курсе :) Mine-ите coin-ы на своей игровой видеокарте? Успешно?
	Ответить | Правка | ^ к родителю #48 | Наверх | Cообщить модератору

	51. "Для PostgreSQL развиваются механизмы ускорения за счёт привл..."	+/–
	Сообщение от Xaionaro (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 (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 on 24-Дек-14, 13:28
Торт.Невероятно крутая штука.
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

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

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

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