forum.opennet.ru - "Релиз СУБД PostgreSQL 9.2" (44)

форумы

помощь

поиск

регистрация

майллист

вход/выход

слежка

"Релиз СУБД PostgreSQL 9.2"

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

"Релиз СУБД PostgreSQL 9.2"	+/–
Сообщение от opennews (??) on 10-Сен-12, 22:15
После года разработки представлен (http://www.postgresql.org/about/news/1415/) релиз новой стабильной ветки PostgreSQL 9.2 (http://www.postgresql.org). Кроме реализации новых функций в новой ветке проведена значительная работа по увеличению производительности и масштабируемости, как горизонтальной (распределение нагрузки на несколько серверов), так и вертикальной (оптимальная работа на больших мощных серверах). В качестве примеров возросшей производительности PostgreSQL приводится способность обрабатывать до 350 тыс. запросов на чтение в секунду (в 4 раза больше чем раньше) и до 14 тысяч запросов на запись в секунду (в 5 раз быстрее). Ключевые улучшения (http://wiki.postgresql.org/wiki/What%27s_new_in_Postgre...): - Поддержка (http://www.postgresql.org/docs/9.2/static/datatype-json.html) типа данных JSON и встроенные средства для манипулирования данными в формате JSON, что позволяет создавать гибридные документо-реаляционные базы данных. Дополнительно представлен набор сопутствующих функций для преобразования массивов и строк в JSON-представление; - Новые типы (http://www.postgresql.org/docs/devel/static/rangetypes.html) для определения диапазонов (INT4RANGE, INT8RANGE, NUMRANGE, TSRANGE, TSTZRANGE и DATERANGE), которые могут быть использованы в календарях, временных рядах и аналитических приложениях; - Расширение возможностей оператора ALTER, упрощающих изменение и обновление структуры работающей БД. Снижение числа ситуаций, когда необходимо перестроение индексов и таблиц при выполнении ALTER TABLE. Поддержка выражения "IF EXIST", позволяющего игнорировать действие если элемент не существует (например, "ALTER FOREIGN TABLE IF EXISTS foo RENAME TO bar"). Добавлены выражения: ALTER FOREIGN DATA WRAPPER / RENAME, ALTER SERVER / RENAME, ALTER DOMAIN / RENAME; - Поддержка (http://www.postgresql.org/docs/9.2/static/warm-standby.html#...) каскадных репликаций, при которых допускается репликация между slave-серверами (ранее slave-сервер мог получать данные только от master-сервера). Возможность создания территориально распределённых реплицированных резервных БД; - Включение в поставку утилиты pg_receivexlog (http://www.postgresql.org/docs/9.2/static/app-pgreceivexlog....) для архивирования изменений в файлах xlog по мере записи данных, не дожидаясь окончания полного формирования xlog-файла; - Добавление в утилиту pg_basebackup (http://www.postgresql.org/docs/9.2/static/app-pgbasebackup.html) возможности создания основных резервных копий, используя данные с запасных standby-серверов, что позволяет снять нагрузку с основного сервера в процессе создания бэкапа; - В представлениях (http://www.postgresql.org/docs/9.2/static/sql-createview.html) добавлена поддержка опции security_barrier для обеспечения изоляции (http://www.postgresql.org/docs/9.2/static/rules-privileges.html) на уровне строк; - В libpq добавлена возможность указания строки инициирования соединения в форме URI. В libpq обеспечен однострочный (single-row) режим обработки запросов, позволяющий улучшить обработку больших результирующих наборов данных; - Многочисленные оптимизации производительности, в том числе: - Режим сканирования только по индексам при котором scan-операции манипулируют только содержимым индекса, не обращаясь к базовым таблицам. По заявлению разработчиков, выборка только по индексам позволяет увеличить скорость выполнения аналитических запросов от 2 до 20 раз; - Расширены возможности масштабирования работающих только на чтение конфгураций, поддерживается задействование до 64 процессорных ядер и обеспечения производительности на одном сервере на уровне сотен тысяч запросов в секунду; - Ускорены операции записи данных, включая выполнение групповых коммитов; - В планировщик выполнения запросов добавлена поддержка генерации отдельных планов выполнения запроса для специфичных значений параметров; - Улучшение возможности планировщика запросов по использованию вложенных циклов при внутренних сканированиях индекса; - Поддержка метода доступа к индексам SP-GiST (http://www.postgresql.org/docs/9.2/static/spgist.html) (Space-Partitioned GiST); - Снижена нагрузка на CPU в периоды простоя сервера, что позволило снизить потребление энергии и улучшить работу на встраиваемых системах и при использовании виртуализации; - Проведена оптимизация производительности операций сортировки данных в памяти, что позволило добиться в некоторых ситуациях ускорения до 25%; - Оптимизировано выполнение операции COPY, которая теперь приводит к установке меньшего числа внутритабличных блокировок и к генерации меньшего объема записей в WAL-лог. URL: http://www.postgresql.org/about/news/1415/ Новость: http://www.opennet.ru/opennews/art.shtml?num=34794
Ответить \| Правка \| Cообщить модератору

Оглавление

Релиз СУБД PostgreSQL 9.2, Аноним, 22:22 , 10-Сен-12, (3) +2

Релиз СУБД PostgreSQL 9.2, sam002_tmp, 22:44 , 10-Сен-12, (4)

Релиз СУБД PostgreSQL 9.2, Аноним, 23:00 , 10-Сен-12, (6)

Релиз СУБД PostgreSQL 9.2, anonymous, 23:28 , 10-Сен-12, (9) +1

Релиз СУБД PostgreSQL 9.2, Аноним, 23:44 , 10-Сен-12, (13) –1

Релиз СУБД PostgreSQL 9.2, Аноним, 14:25 , 11-Сен-12, (29)

Релиз СУБД PostgreSQL 9.2, Аноним, 00:03 , 11-Сен-12, (14)

Релиз СУБД PostgreSQL 9.2, Аноним, 00:23 , 11-Сен-12, (18)

Релиз СУБД PostgreSQL 9.2, Аноним, 00:45 , 11-Сен-12, (19)

Релиз СУБД PostgreSQL 9.2, o, 09:42 , 11-Сен-12, (24)

Релиз СУБД PostgreSQL 9.2, sam002_tmp, 23:42 , 10-Сен-12, (11) +2

Релиз СУБД PostgreSQL 9.2, Аноним, 00:08 , 11-Сен-12, (15)

Релиз СУБД PostgreSQL 9.2, sam002_tmp, 01:46 , 11-Сен-12, (22)

Релиз СУБД PostgreSQL 9.2, sam002_tmp, 02:01 , 11-Сен-12, (23) +2

Релиз СУБД PostgreSQL 9.2, Аноним, 00:21 , 11-Сен-12, (17) +1

Релиз СУБД PostgreSQL 9.2, Аноним, 00:17 , 11-Сен-12, (16)

Релиз СУБД PostgreSQL 9.2, Аноним, 01:01 , 11-Сен-12, (20)

Релиз СУБД PostgreSQL 9.2, all_glory_to_the_hypnotoad, 01:19 , 11-Сен-12, (21) +5
Релиз СУБД PostgreSQL 9.2, vovans, 22:20 , 11-Сен-12, (39)

Релиз СУБД PostgreSQL 9.2, Михрютка, 12:39 , 11-Сен-12, (25)

Релиз СУБД PostgreSQL 9.2, ананим, 13:50 , 11-Сен-12, (26) +1

Релиз СУБД PostgreSQL 9.2, Михрютка, 14:18 , 11-Сен-12, (28) +1

Релиз СУБД PostgreSQL 9.2, ананим, 15:42 , 11-Сен-12, (31)

Релиз СУБД PostgreSQL 9.2, Михрютка, 18:16 , 11-Сен-12, (32)

Релиз СУБД PostgreSQL 9.2, ананим, 18:42 , 11-Сен-12, (33)

Релиз СУБД PostgreSQL 9.2, Михрютка, 19:11 , 11-Сен-12, (35)

Релиз СУБД PostgreSQL 9.2, ананим, 22:02 , 11-Сен-12, (36)

Релиз СУБД PostgreSQL 9.2, Andrey Mitrofanov, 22:39 , 12-Сен-12, (47)

Релиз СУБД PostgreSQL 9.2, Аноним, 01:15 , 13-Сен-12, (49) –1

Релиз СУБД PostgreSQL 9.2, XoRe, 23:34 , 12-Сен-12, (48)

Релиз СУБД PostgreSQL 9.2, Аноним, 01:32 , 13-Сен-12, (50)
Релиз СУБД PostgreSQL 9.2, stopa85, 12:41 , 13-Сен-12, (51)

Релиз СУБД PostgreSQL 9.2, XoRe, 14:27 , 13-Сен-12, (52)

Релиз СУБД PostgreSQL 9.2, Аноним, 14:44 , 13-Сен-12, (53)
Релиз СУБД PostgreSQL 9.2, Михрютка, 16:51 , 13-Сен-12, (54)

Релиз СУБД PostgreSQL 9.2, sam002_tmp, 22:50 , 10-Сен-12, (5) –3

Релиз СУБД PostgreSQL 9.2, Аноним, 23:14 , 10-Сен-12, (7) +3
Релиз СУБД PostgreSQL 9.2, Аноним, 23:43 , 10-Сен-12, (12) +1

Релиз СУБД PostgreSQL 9.2, Владимир Z, 14:07 , 11-Сен-12, (27) +6
Релиз СУБД PostgreSQL 9.2, pivo, 15:29 , 11-Сен-12, (30)

Релиз СУБД PostgreSQL 9.2, www2, 19:04 , 11-Сен-12, (34)

Релиз СУБД PostgreSQL 9.2, Аноним, 22:15 , 11-Сен-12, (37) +1

Релиз СУБД PostgreSQL 9.2, Аноним, 00:41 , 12-Сен-12, (42)
Релиз СУБД PostgreSQL 9.2, www2, 17:10 , 10-Окт-12, (55)

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

3. "Релиз СУБД PostgreSQL 9.2" +2 +/–

Сообщение от Аноним (??) on 10-Сен-12, 22:22

Блин, а ктонить в курсе, полное задействование проца (всех ядер) для одного запроса, т.е. его распараллеливание, когданить сделают? или это для постгреса не реально?

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

4. "Релиз СУБД PostgreSQL 9.2" +/–

Сообщение от sam002_tmp on 10-Сен-12, 22:44

Вы что из БД сделали?! А так, всё зависит от структуры запроса... Если вы используете функции для обработки, то всё хорошо и ядра все отработают и удалённые сервера через midleware можно вызвать))

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

6. "Релиз СУБД PostgreSQL 9.2" +/–

Сообщение от Аноним (??) on 10-Сен-12, 23:00

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

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

9. "Релиз СУБД PostgreSQL 9.2" +1 +/–

Сообщение от anonymous (??) on 10-Сен-12, 23:28

Жесткий тоже паралельно таблицу читать будет? Или Partitioning используется?.

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

13. "Релиз СУБД PostgreSQL 9.2" –1 +/–

Сообщение от Аноним (??) on 10-Сен-12, 23:44

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

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

29. "Релиз СУБД PostgreSQL 9.2" +/–

Сообщение от Аноним (??) on 11-Сен-12, 14:25

всегда в диск упирается, если у вас все данные в память влезают то вам и база не нужна :)

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

14. "Релиз СУБД PostgreSQL 9.2" +/–

Сообщение от Аноним (??) on 11-Сен-12, 00:03

Можно было бы понять если бы недозагружалось даже одно ядро, но он его под завязку выгребает, а значит хочет еще

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

18. "Релиз СУБД PostgreSQL 9.2" +/–

Сообщение от Аноним (??) on 11-Сен-12, 00:23

pg под каждый коннект использует отдельный процесс с одним рабочим потоком, в этом у вас и вся проблема. Иначе pg пока работать не умеет. В прочем, не только он один среди открытых субд.

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

19. "Релиз СУБД PostgreSQL 9.2" +/–

Сообщение от Аноним (??) on 11-Сен-12, 00:45

Досадно это, понятно что для многоконнектной системы это не проблема, но в один коннект проще, если бы он внутри базой распараллеливался было бы шикарно)

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

24. "Релиз СУБД PostgreSQL 9.2" +/–

Сообщение от o on 11-Сен-12, 09:42

Юзай pool Люк.

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

11. "Релиз СУБД PostgreSQL 9.2" +2 +/–

Сообщение от sam002_tmp on 10-Сен-12, 23:42

PL/pgSQL Позволяет делать любые безобразия. Если, например, речь о SELECT, то там порядок вывода играет роль и делать его многопоточно нетривиальная задача. Если в целом, то для чистого sql: один запрос - один поток. Если же запускать выполнение pgSQL функции, то можно брать диапазоны из таблицы, отправлять дополнительные запросы (http://www.postgresql.org/docs/9.2/interactive/dblink.html). Любой же интерфейс поддерживает многопоточность (libpq, python, perl).
Если ваш запрос упёрся в производительность проца, а не памяти/диска, то пора читать мануал.

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

15. "Релиз СУБД PostgreSQL 9.2" +/–

Сообщение от Аноним (??) on 11-Сен-12, 00:08

Ну а что там еще читать? Большие таблицы, где надо - индексы, на тяжелых запросах всегда полностью загружено одно ядро, очевидно что в него и упирается, не ну винт тоже конечно в напряге, но он хоть изредка помаргивает а ядро под завязку.

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

22. "Релиз СУБД PostgreSQL 9.2" +/–

Сообщение от sam002_tmp on 11-Сен-12, 01:46

Ну... Я пол-года назад внутренностями postgres реализовывал перенос WP. Работало быстрее, чем NGINX и стандартные плагины WP для кеша.

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

23. "Релиз СУБД PostgreSQL 9.2" +2 +/–

Сообщение от sam002_tmp on 11-Сен-12, 02:01

> Ну... Я пол-года назад внутренностями postgres реализовывал перенос WP. Работало быстрее,
> чем NGINX и стандартные плагины WP для кеша.
Спать, спать, спать... Уже не по теме отвечаю.
Суть - хорошо продуманный алгоритм на порядки эффективнее нового железа и "фич". Для реализации у postgres много инструмента, но вести какие-то вычисления необходимо в отдельных модулях.
Упираться в производительность железа - сигнал к рефакторингу и расширению. Может быть вас устраивает задержка и проблемы нет?

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

17. "Релиз СУБД PostgreSQL 9.2" +1 +/–

Сообщение от Аноним (??) on 11-Сен-12, 00:21

он то как раз хочет чтобы субд была субд, а не бд, понимаешь разницу? Твои эти мидлваре и dblink'и просто костыли, воркэраунды из-за отсутствия нормальной реализации фичи со стороны субд.

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

16. "Релиз СУБД PostgreSQL 9.2" +/–

Сообщение от Аноним (??) on 11-Сен-12, 00:17

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

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

20. "Релиз СУБД PostgreSQL 9.2" +/–

Сообщение от Аноним (??) on 11-Сен-12, 01:01

Странно както, количество ядер растет, производительность дисковой подсистемы увеличивается, по идее этот вопрос будет все острее и острее, а у них насколько я знаю этого даже в широких планах нет, какието отдельные вещи параллелят но не сам основной движок, а ведь такое изменение наверное очень много за собой потянет, как бы фигня не созрела.

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

21. "Релиз СУБД PostgreSQL 9.2" +5 +/–

Сообщение от all_glory_to_the_hypnotoad (ok) on 11-Сен-12, 01:19

для OLTP нагрузки этого не нужно (т.е. паттерн обслуживания множества пользователей, вебня и прочая херня).
для аналитки (DWH, OLAP) pg либо настраивают специальным образом (вероятно, под ваши запросы можно сделать специальный конфиг и выполнение больше не будет упираться в ядро. Нужно смотреть на каких именно операциях проседает), либо делать шардинг по нескольким субд вашей бд.
в общем, через костыли, но проблема часто как-то решаема.
> а у них насколько я знаю этого даже в широких планах нет, какието отдельные вещи параллелят но не сам основной движок
Его не просто распараллелить, прежде, например, нужно сделать нормальное партиционирование, а потом вашу задачу. Вот голосовалка фич pg:
http://postgresql.uservoice.com/forums/21853-general
Ваш кейс стоит на 3ем месте, так что скорее всего его скоро начнут делать.

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

39. "Релиз СУБД PostgreSQL 9.2" +/–

Сообщение от vovans (ok) on 11-Сен-12, 22:20

На серверах всегда было много ядер и быстрые диски. Это на десктопах кол-во ядер растёт.

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

25. "Релиз СУБД PostgreSQL 9.2" +/–

Сообщение от Михрютка (ok) on 11-Сен-12, 12:39

а дак начинали вроде делать, но заглохло. станичка в постгресовской вики с 2009 года висит с недописанным туду.
динамическое партиционирование и параллельные запросы - штука нетривиальная, пока кого-то из клиентов с толстыми ЕТЛ запросами не припрет, и он сам не напишет или не заплатит, вряд ли кто не пошевелится. кто будет юзать ворованный оракл, кто - покупной мссикель.

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

26. "Релиз СУБД PostgreSQL 9.2" +1 +/–

Сообщение от ананим on 11-Сен-12, 13:50

можно подумать мссиквел намного дальше ушёл, ха!
зыж
и почему оракл ворованный, а мссиквел купленный?
стандартная редакция оракла даже дешевле мссиквела, а если говорим уже о таких вот нагрузках, то без сервиспаков на ворованном далеко не уедешь.

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

28. "Релиз СУБД PostgreSQL 9.2" +1 +/–

Сообщение от Михрютка (ok) on 11-Сен-12, 14:18

> можно подумать мссиквел намного дальше ушёл, ха!
по сравнению с нулем - не вижу смысла обсуждать, намного или ненамного. что смущает-то?
> зыж
> и почему оракл ворованный, а мссиквел купленный?
> стандартная редакция оракла даже дешевле мссиквела, а если говорим уже о таких
> вот нагрузках, то без сервиспаков на ворованном далеко не уедешь.
"если уж говорим о таких вот нагрузках", то 4-сокетовый вариант оракла да, он в тему.
последний раз, как я проверял, разница была сильно не в пользу оракла, но это было давно, возможно, что-то изменилось. и в любом случае совершщенно неважно. я мог бы написать "ворованный информикс" и "купленный сайбейс", сути примера это не изменило бы. разве что вылез бы какой-нибудь информикс-фаг и начал нудить "А чо сразу информикс?"

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

31. "Релиз СУБД PostgreSQL 9.2" +/–

Сообщение от ананим on 11-Сен-12, 15:42

>по сравнению с нулем - не вижу смысла обсуждать, намного или ненамного. что смущает-то?
с нулём? :D
угу
http://www.sql.ru/articles/mssql/2004/04112301resolvingblock...
>Блокировки присутствуют в любой реляционной системе управления базами данных (СУБД), т.к. на блокировках основана работа механизма обслуживания параллельных запросов.
в синтетических тестах это да, прокатывает. в реальной системе только мешает.
ха! блокировки при селекте - фича на любителей. из разряда кожаных масках.
зыж
фичи коммерческих субд порой больше рассчитаны на рекламный проспект, чем на использование.
хотя именно в данном конкретном случае оракл хоть это умеет правильно.

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

32. "Релиз СУБД PostgreSQL 9.2" +/–

Сообщение от Михрютка (ok) on 11-Сен-12, 18:16

> http://www.sql.ru/articles/mssql/2004/04112301resolvingblock...
>>Блокировки присутствуют в любой реляционной системе управления базами данных (СУБД), т.к. на блокировках основана работа механизма обслуживания параллельных запросов.
facepalm.jpg

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

33. "Релиз СУБД PostgreSQL 9.2" +/–

Сообщение от ананим on 11-Сен-12, 18:42

чё сказать то хотел?
пояснения требуются?
>>>Блокировки присутствуют в любой реляционной системе управления базами данных (СУБД), т.к. на блокировках основана работа механизма обслуживания параллельных запросов.
блокировки то присутствуют в любой РСУБД, но НЕ в любой на блокировках основана работа механизма обслуживания параллельных запросов. :D

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

35. "Релиз СУБД PostgreSQL 9.2" +/–

Сообщение от Михрютка (ok) on 11-Сен-12, 19:11

> чё сказать то хотел?
> пояснения требуются?
>>>>Блокировки присутствуют в любой реляционной системе управления базами данных (СУБД), т.к. на блокировках основана работа механизма обслуживания параллельных запросов.
> блокировки то присутствуют в любой РСУБД, но НЕ в любой на блокировках
> основана работа механизма обслуживания параллельных запросов. :D
вы ради разнообразия не пробовали прочесть тред, в который так удачно ворвались, _до_того_, как постить первое, что попалось в яндексе по словам "параллельные запросы"?

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

36. "Релиз СУБД PostgreSQL 9.2" +/–

Сообщение от ананим on 11-Сен-12, 22:02

Хо!
В яндексе ещё надо знать какой вопрос задавать.
А посему, ваши не нулевые параллельные запросы в мсиквеле разбиваются о блокировки, которые он при этом использует.
Так что пользы от них на практике тотже 0. Вне зависимости какой у вас поисковик.:D

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

47. "Релиз СУБД PostgreSQL 9.2" +/–

Сообщение от Andrey Mitrofanov on 12-Сен-12, 22:39

> Блин, а ктонить в курсе, полное задействование проца (всех ядер) для одного
> запроса, т.е. его распараллеливание, когданить сделают? или это для постгреса не
> реально?
Чего конкретно http://www.postgresql.org/docs/9.1/static/geqo-intro.html не хватает?
Какие http://www.postgresql.org/docs/7.1/static/geqo.html#GEQO-INTRO слова не понятны?

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

49. "Релиз СУБД PostgreSQL 9.2" –1 +/–

Сообщение от Аноним (??) on 13-Сен-12, 01:15

Понятно что параллелить построение плана сложно, но когда он построен, почему бы не распараллелить его исполнение? В простейшем случае если известно что придется просмотреть определенный диапазон строк, то почему бы не разделить его на поддиапазоны и не натравить на каждый отдельное ядро?

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

48. "Релиз СУБД PostgreSQL 9.2" +/–

Сообщение от XoRe (ok) on 12-Сен-12, 23:34

> Блин, а ктонить в курсе, полное задействование проца (всех ядер) для одного
> запроса, т.е. его распараллеливание, когданить сделают? или это для постгреса не
> реально?
Когда у вас будет 10-100 одновременных запросов к БД и будут загружены даже 24 ядра, вы поймете, что 1 запрос на ядро - это благо)
Лучше запрос одним ядром обрабатывается и не тратит время на переключения ядер.
А если у вас 1-2 одновременных запроса к БД, нужно менять логику работы с БД, если хотите параллелить.
Самым узким местом должен быть жесткий.
Если узкое место в чем-то другом, значит, есть место для оптимизации)

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

50. "Релиз СУБД PostgreSQL 9.2" +/–

Сообщение от Аноним (??) on 13-Сен-12, 01:32

Параллельных запросов нет, они приходят редко, по одному, но должны выполняться максимально быстро, в крайнем случае выстраиваются внешней системой в очередь. В том то и дело что невозможно изменить обстоятельства и трудно изменить логику внешних систем, в общем случае я не могу параллелить запросы, мне нужно чтобы параллелился 1 запрос, это конечно можно сделать извне, но согласитесь было бы лучше если бы это делала база, по логике это ее задача.
И почему узким местом должен быть жесткий? база это не набор готовых данных, это место хранения и обработки данных "средней степени сжатия" ибо запросы могут быть разные и есть требования по объему, а значит место вычислениям всегда есть. Оптимизация всегда выполняется относительно свободных ресурсов, в данном случае у меня свободен проц, почему бы не "упаковать" данные для экономии винта чтобы в него не упиралось, и при этом не задействовать свободный проц выполнив задачу быстрее? В винт упереться недолго, но при этом простаивает проц, в этом случае по моему глупо упираться в винт и говорить что так и должно быть.

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

51. "Релиз СУБД PostgreSQL 9.2" +/–

Сообщение от stopa85 (ok) on 13-Сен-12, 12:41

Мое мнение что 1 запрос-одно ядро хорошо для OLTP систем,
1 запрос-много ядер может быть хорошо для OLAP систем, особенно для "гибридных" систем, когда данные храняться в несовсем оптимальном для OLAP-систем виде.
Как бы там нибыло, на эту фишку есть спрос - значит и ситуации когда она необходима бывают.

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

52. "Релиз СУБД PostgreSQL 9.2" +/–

Сообщение от XoRe (ok) on 13-Сен-12, 14:27

> Мое мнение что 1 запрос-одно ядро хорошо для OLTP систем,
> 1 запрос-много ядер может быть хорошо для OLAP систем, особенно для "гибридных"
> систем, когда данные храняться в несовсем оптимальном для OLAP-систем виде.
> Как бы там нибыло, на эту фишку есть спрос - значит и
> ситуации когда она необходима бывают.
Для удовлетворения этого спроса уже сейчас есть предложения - кластеры, масштабируемые БД и т.д.
Например, можно использовать MongoDB - развести инфу по куче узлов.
И работать с данными в стиле MapReduce.
Будет очень шустро.
Если не хочется велосипедить, можно взять уже существующие OLAP системы.
Хотя они, вроде бы, не дешевые.
P.S.
Но всегда можно сказать "не не не, я не хочу ничего менять, я подожду, пока программисты Postgresql сделают это для меня бесплатно")

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

53. "Релиз СУБД PostgreSQL 9.2" +/–

Сообщение от Аноним (??) on 13-Сен-12, 14:44

Гражданин начальник говорит раз постгрес так не может значит нах его, досадно однако.

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

54. "Релиз СУБД PostgreSQL 9.2" +/–

Сообщение от Михрютка (ok) on 13-Сен-12, 16:51

> Когда у вас будет 10-100 одновременных запросов к БД и будут загружены
> даже 24 ядра, вы поймете, что 1 запрос на ядро -
> это благо)
> Лучше запрос одним ядром обрабатывается и не тратит время на переключения ядер.
> А если у вас 1-2 одновременных запроса к БД, нужно менять логику
> работы с БД, если хотите параллелить.
> Самым узким местом должен быть жесткий.
> Если узкое место в чем-то другом, значит, есть место для оптимизации)
Made my day.
> Для удовлетворения этого спроса уже сейчас есть предложения - кластеры, масштабируемые
> БД и т.д.
> Например, можно использовать MongoDB - развести инфу по куче узлов.
> И работать с данными в стиле MapReduce.
> Будет очень шустро.
Twice.

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

5. "Релиз СУБД PostgreSQL 9.2" –3 +/–

Сообщение от sam002_tmp on 10-Сен-12, 22:50

Отлично... JSON, интервалы, м-м-м!
Темпы разработки очень сильно пугают - в debian stable ещё нет 9.1, а они уже 9.2 пустили. Подскажите, а есть ли у postgres постоянные выпуски (помимо development) и LT версии?

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

7. "Релиз СУБД PostgreSQL 9.2" +3 +/–

Сообщение от Аноним (??) on 10-Сен-12, 23:14

Да ладно вам) пугают) Одна новая стабильная версия в год, потом каждая 3-5 лет поддерживается, на протяжении этого времени для каждой выходят доработки, оптимизации, исправления - по моему отлично, чем не LT? Сходите на офсайт и посмотрите. Ну а что там debian для вас заготовил это чисто ваши проблемы.

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

12. "Релиз СУБД PostgreSQL 9.2" +1 +/–

Сообщение от Аноним (??) on 10-Сен-12, 23:43

Разработчики PostgreSQL поддерживают четыре ветки одновременно + ветка разработки.

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

27. "Релиз СУБД PostgreSQL 9.2" +6 +/–

Сообщение от Владимир Z on 11-Сен-12, 14:07

Самая классная реляционная СУБД для проектов любого масштаба (от небольших сайтов до корпоративного учета).
Молодцы! Еще и такой прогресс.

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

30. "Релиз СУБД PostgreSQL 9.2" +/–

Сообщение от pivo on 11-Сен-12, 15:29

JDBC драйвер что то у них не обновился.

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

34. "Релиз СУБД PostgreSQL 9.2" +/–

Сообщение от www2 (??) on 11-Сен-12, 19:04

А что там обновлять-то? По-моему клиентом MySQL от 3 версии до сих пор можно подключаться к MySQL хоть 5-й версии.

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

37. "Релиз СУБД PostgreSQL 9.2" +1 +/–

Сообщение от Аноним (??) on 11-Сен-12, 22:15

> А что там обновлять-то? По-моему клиентом MySQL от 3 версии до сих
> пор можно подключаться к MySQL хоть 5-й версии.
можно, но это же не значит что он будет использовать новые функции, а в 9.2 появилась такая штука как построчное получение данных с сервера без курсора.

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

42. "Релиз СУБД PostgreSQL 9.2" +/–

Сообщение от Аноним (??) on 12-Сен-12, 00:41

> можно, но это же не значит что он будет использовать новые функции,
> а в 9.2 появилась такая штука как построчное получение данных с
> сервера без курсора.
ну так это в libpq, текущая версия JDBC libpq не использует.
Другое дело, добавить поддержку новых типов.

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

55. "Релиз СУБД PostgreSQL 9.2" +/–

Сообщение от www2 (??) on 10-Окт-12, 17:10

>> А что там обновлять-то? По-моему клиентом MySQL от 3 версии до сих
>> пор можно подключаться к MySQL хоть 5-й версии.
> можно, но это же не значит что он будет использовать новые функции,
> а в 9.2 появилась такая штука как построчное получение данных с
> сервера без курсора.
Это что же, до сих пор нельзя было обрабатывать таблицы не умещающиеся в оперативной памяти?
А то я вот недавно с удивлением обнаружил, что клиент MySQL (любой, касается и консольного и Perl DBI и PHP) по умолчанию при выполнении селекта сначала всасывает в оперативку результат запроса целиком. Долго ломал голову, как мне слить нужные данные из таблицы в 70 гигабайт, потом всё-таки нашёл решение.

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

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

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

Партнёры:

Хостинг:

Закладки на сайте
Проследить за страницей

Created 1996-2024 by Maxim Chirkov
Добавить, Поддержать, Вебмастеру

3. "Релиз СУБД PostgreSQL 9.2"	+2 +/–
Сообщение от Аноним (??) on 10-Сен-12, 22:22
Блин, а ктонить в курсе, полное задействование проца (всех ядер) для одного запроса, т.е. его распараллеливание, когданить сделают? или это для постгреса не реально?
Ответить \| Правка \| ^ к родителю #0 \| Наверх \| Cообщить модератору


	4. "Релиз СУБД PostgreSQL 9.2"	+/–
	Сообщение от sam002_tmp on 10-Сен-12, 22:44
	Вы что из БД сделали?! А так, всё зависит от структуры запроса... Если вы используете функции для обработки, то всё хорошо и ядра все отработают и удалённые сервера через midleware можно вызвать))
	Ответить \| Правка \| ^ к родителю #3 \| Наверх \| Cообщить модератору


	6. "Релиз СУБД PostgreSQL 9.2"	+/–
	Сообщение от Аноним (??) on 10-Сен-12, 23:00
	Да не, удаленных никаких нет, а вот про функции не понял, сколько и как чего не делаю (один коннект/запрос) всегда загружено только одно ядро, и просто запрос и свои хранимки с циклами/курсорами и использованием встроенных функций - по любому на один коннект/запрос используется только одно ядро, досадно, большая таблица и по ней относительно не сложный запрос который можно было бы распараллелить, ибо просматривает все записи, ну и соответственно выполнить быстрее, однако нет - исполняет в один поток, проц недогружен.
	Ответить \| Правка \| ^ к родителю #4 \| Наверх \| Cообщить модератору


	9. "Релиз СУБД PostgreSQL 9.2"	+1 +/–
	Сообщение от anonymous (??) on 10-Сен-12, 23:28
	Жесткий тоже паралельно таблицу читать будет? Или Partitioning используется?.
	Ответить \| Правка \| ^ к родителю #6 \| Наверх \| Cообщить модератору


	13. "Релиз СУБД PostgreSQL 9.2"	–1 +/–
	Сообщение от Аноним (??) on 10-Сен-12, 23:44
	Хм, не используется, но ведь далеко не всегда в диск все упирается? индексы, разные встроенные функции, если бы оно могло утилизировать весь проц то уж когднанить заметил бы, или вы хотите сказать что овчинка того не стоит, т.е. в подавляющем большинстве случаев толку от распараллеливания по процу будет чуть?
	Ответить \| Правка \| ^ к родителю #9 \| Наверх \| Cообщить модератору


	29. "Релиз СУБД PostgreSQL 9.2"	+/–
	Сообщение от Аноним (??) on 11-Сен-12, 14:25
	всегда в диск упирается, если у вас все данные в память влезают то вам и база не нужна :)
	Ответить \| Правка \| ^ к родителю #13 \| Наверх \| Cообщить модератору


	14. "Релиз СУБД PostgreSQL 9.2"	+/–
	Сообщение от Аноним (??) on 11-Сен-12, 00:03
	Можно было бы понять если бы недозагружалось даже одно ядро, но он его под завязку выгребает, а значит хочет еще
	Ответить \| Правка \| ^ к родителю #9 \| Наверх \| Cообщить модератору


	18. "Релиз СУБД PostgreSQL 9.2"	+/–
	Сообщение от Аноним (??) on 11-Сен-12, 00:23
	pg под каждый коннект использует отдельный процесс с одним рабочим потоком, в этом у вас и вся проблема. Иначе pg пока работать не умеет. В прочем, не только он один среди открытых субд.
	Ответить \| Правка \| ^ к родителю #14 \| Наверх \| Cообщить модератору


	19. "Релиз СУБД PostgreSQL 9.2"	+/–
	Сообщение от Аноним (??) on 11-Сен-12, 00:45
	Досадно это, понятно что для многоконнектной системы это не проблема, но в один коннект проще, если бы он внутри базой распараллеливался было бы шикарно)
	Ответить \| Правка \| ^ к родителю #18 \| Наверх \| Cообщить модератору


	24. "Релиз СУБД PostgreSQL 9.2"	+/–
	Сообщение от o on 11-Сен-12, 09:42
	Юзай pool Люк.
	Ответить \| Правка \| ^ к родителю #19 \| Наверх \| Cообщить модератору


	11. "Релиз СУБД PostgreSQL 9.2"	+2 +/–
	Сообщение от sam002_tmp on 10-Сен-12, 23:42
	PL/pgSQL Позволяет делать любые безобразия. Если, например, речь о SELECT, то там порядок вывода играет роль и делать его многопоточно нетривиальная задача. Если в целом, то для чистого sql: один запрос - один поток. Если же запускать выполнение pgSQL функции, то можно брать диапазоны из таблицы, отправлять дополнительные запросы (http://www.postgresql.org/docs/9.2/interactive/dblink.html). Любой же интерфейс поддерживает многопоточность (libpq, python, perl). Если ваш запрос упёрся в производительность проца, а не памяти/диска, то пора читать мануал.
	Ответить \| Правка \| ^ к родителю #6 \| Наверх \| Cообщить модератору


	15. "Релиз СУБД PostgreSQL 9.2"	+/–
	Сообщение от Аноним (??) on 11-Сен-12, 00:08
	Ну а что там еще читать? Большие таблицы, где надо - индексы, на тяжелых запросах всегда полностью загружено одно ядро, очевидно что в него и упирается, не ну винт тоже конечно в напряге, но он хоть изредка помаргивает а ядро под завязку.
	Ответить \| Правка \| ^ к родителю #11 \| Наверх \| Cообщить модератору


	22. "Релиз СУБД PostgreSQL 9.2"	+/–
	Сообщение от sam002_tmp on 11-Сен-12, 01:46
	Ну... Я пол-года назад внутренностями postgres реализовывал перенос WP. Работало быстрее, чем NGINX и стандартные плагины WP для кеша.
	Ответить \| Правка \| ^ к родителю #15 \| Наверх \| Cообщить модератору


	23. "Релиз СУБД PostgreSQL 9.2"	+2 +/–
	Сообщение от sam002_tmp on 11-Сен-12, 02:01
	> Ну... Я пол-года назад внутренностями postgres реализовывал перенос WP. Работало быстрее, > чем NGINX и стандартные плагины WP для кеша. Спать, спать, спать... Уже не по теме отвечаю. Суть - хорошо продуманный алгоритм на порядки эффективнее нового железа и "фич". Для реализации у postgres много инструмента, но вести какие-то вычисления необходимо в отдельных модулях. Упираться в производительность железа - сигнал к рефакторингу и расширению. Может быть вас устраивает задержка и проблемы нет?
	Ответить \| Правка \| ^ к родителю #22 \| Наверх \| Cообщить модератору


	17. "Релиз СУБД PostgreSQL 9.2"	+1 +/–
	Сообщение от Аноним (??) on 11-Сен-12, 00:21
	он то как раз хочет чтобы субд была субд, а не бд, понимаешь разницу? Твои эти мидлваре и dblink'и просто костыли, воркэраунды из-за отсутствия нормальной реализации фичи со стороны субд.
	Ответить \| Правка \| ^ к родителю #4 \| Наверх \| Cообщить модератору


	16. "Релиз СУБД PostgreSQL 9.2"	+/–
	Сообщение от Аноним (??) on 11-Сен-12, 00:17
	когда-нибудь да сделают, всё реально. Но хз когда это наступит, там есть более актуальные задачи на ближайшее время
	Ответить \| Правка \| ^ к родителю #3 \| Наверх \| Cообщить модератору


	20. "Релиз СУБД PostgreSQL 9.2"	+/–
	Сообщение от Аноним (??) on 11-Сен-12, 01:01
	Странно както, количество ядер растет, производительность дисковой подсистемы увеличивается, по идее этот вопрос будет все острее и острее, а у них насколько я знаю этого даже в широких планах нет, какието отдельные вещи параллелят но не сам основной движок, а ведь такое изменение наверное очень много за собой потянет, как бы фигня не созрела.
	Ответить \| Правка \| ^ к родителю #16 \| Наверх \| Cообщить модератору


	21. "Релиз СУБД PostgreSQL 9.2"	+5 +/–
	Сообщение от all_glory_to_the_hypnotoad (ok) on 11-Сен-12, 01:19
	для OLTP нагрузки этого не нужно (т.е. паттерн обслуживания множества пользователей, вебня и прочая херня). для аналитки (DWH, OLAP) pg либо настраивают специальным образом (вероятно, под ваши запросы можно сделать специальный конфиг и выполнение больше не будет упираться в ядро. Нужно смотреть на каких именно операциях проседает), либо делать шардинг по нескольким субд вашей бд. в общем, через костыли, но проблема часто как-то решаема. > а у них насколько я знаю этого даже в широких планах нет, какието отдельные вещи параллелят но не сам основной движок Его не просто распараллелить, прежде, например, нужно сделать нормальное партиционирование, а потом вашу задачу. Вот голосовалка фич pg: http://postgresql.uservoice.com/forums/21853-general Ваш кейс стоит на 3ем месте, так что скорее всего его скоро начнут делать.
	Ответить \| Правка \| ^ к родителю #20 \| Наверх \| Cообщить модератору


	39. "Релиз СУБД PostgreSQL 9.2"	+/–
	Сообщение от vovans (ok) on 11-Сен-12, 22:20
	На серверах всегда было много ядер и быстрые диски. Это на десктопах кол-во ядер растёт.
	Ответить \| Правка \| ^ к родителю #20 \| Наверх \| Cообщить модератору


	25. "Релиз СУБД PostgreSQL 9.2"	+/–
	Сообщение от Михрютка (ok) on 11-Сен-12, 12:39
	а дак начинали вроде делать, но заглохло. станичка в постгресовской вики с 2009 года висит с недописанным туду. динамическое партиционирование и параллельные запросы - штука нетривиальная, пока кого-то из клиентов с толстыми ЕТЛ запросами не припрет, и он сам не напишет или не заплатит, вряд ли кто не пошевелится. кто будет юзать ворованный оракл, кто - покупной мссикель.
	Ответить \| Правка \| ^ к родителю #3 \| Наверх \| Cообщить модератору


	26. "Релиз СУБД PostgreSQL 9.2"	+1 +/–
	Сообщение от ананим on 11-Сен-12, 13:50
	можно подумать мссиквел намного дальше ушёл, ха! зыж и почему оракл ворованный, а мссиквел купленный? стандартная редакция оракла даже дешевле мссиквела, а если говорим уже о таких вот нагрузках, то без сервиспаков на ворованном далеко не уедешь.
	Ответить \| Правка \| ^ к родителю #25 \| Наверх \| Cообщить модератору


	28. "Релиз СУБД PostgreSQL 9.2"	+1 +/–
	Сообщение от Михрютка (ok) on 11-Сен-12, 14:18
	> можно подумать мссиквел намного дальше ушёл, ха! по сравнению с нулем - не вижу смысла обсуждать, намного или ненамного. что смущает-то? > зыж > и почему оракл ворованный, а мссиквел купленный? > стандартная редакция оракла даже дешевле мссиквела, а если говорим уже о таких > вот нагрузках, то без сервиспаков на ворованном далеко не уедешь. "если уж говорим о таких вот нагрузках", то 4-сокетовый вариант оракла да, он в тему. последний раз, как я проверял, разница была сильно не в пользу оракла, но это было давно, возможно, что-то изменилось. и в любом случае совершщенно неважно. я мог бы написать "ворованный информикс" и "купленный сайбейс", сути примера это не изменило бы. разве что вылез бы какой-нибудь информикс-фаг и начал нудить "А чо сразу информикс?"
	Ответить \| Правка \| ^ к родителю #26 \| Наверх \| Cообщить модератору


	31. "Релиз СУБД PostgreSQL 9.2"	+/–
	Сообщение от ананим on 11-Сен-12, 15:42
	>по сравнению с нулем - не вижу смысла обсуждать, намного или ненамного. что смущает-то? с нулём? :D угу http://www.sql.ru/articles/mssql/2004/04112301resolvingblock... >Блокировки присутствуют в любой реляционной системе управления базами данных (СУБД), т.к. на блокировках основана работа механизма обслуживания параллельных запросов. в синтетических тестах это да, прокатывает. в реальной системе только мешает. ха! блокировки при селекте - фича на любителей. из разряда кожаных масках. зыж фичи коммерческих субд порой больше рассчитаны на рекламный проспект, чем на использование. хотя именно в данном конкретном случае оракл хоть это умеет правильно.
	Ответить \| Правка \| ^ к родителю #28 \| Наверх \| Cообщить модератору


	32. "Релиз СУБД PostgreSQL 9.2"	+/–
	Сообщение от Михрютка (ok) on 11-Сен-12, 18:16
	> http://www.sql.ru/articles/mssql/2004/04112301resolvingblock... >>Блокировки присутствуют в любой реляционной системе управления базами данных (СУБД), т.к. на блокировках основана работа механизма обслуживания параллельных запросов. facepalm.jpg
	Ответить \| Правка \| ^ к родителю #31 \| Наверх \| Cообщить модератору


	33. "Релиз СУБД PostgreSQL 9.2"	+/–
	Сообщение от ананим on 11-Сен-12, 18:42
	чё сказать то хотел? пояснения требуются? >>>Блокировки присутствуют в любой реляционной системе управления базами данных (СУБД), т.к. на блокировках основана работа механизма обслуживания параллельных запросов. блокировки то присутствуют в любой РСУБД, но НЕ в любой на блокировках основана работа механизма обслуживания параллельных запросов. :D
	Ответить \| Правка \| ^ к родителю #32 \| Наверх \| Cообщить модератору


	35. "Релиз СУБД PostgreSQL 9.2"	+/–
	Сообщение от Михрютка (ok) on 11-Сен-12, 19:11
	> чё сказать то хотел? > пояснения требуются? >>>>Блокировки присутствуют в любой реляционной системе управления базами данных (СУБД), т.к. на блокировках основана работа механизма обслуживания параллельных запросов. > блокировки то присутствуют в любой РСУБД, но НЕ в любой на блокировках > основана работа механизма обслуживания параллельных запросов. :D вы ради разнообразия не пробовали прочесть тред, в который так удачно ворвались, _до_того_, как постить первое, что попалось в яндексе по словам "параллельные запросы"?
	Ответить \| Правка \| ^ к родителю #33 \| Наверх \| Cообщить модератору


	36. "Релиз СУБД PostgreSQL 9.2"	+/–
	Сообщение от ананим on 11-Сен-12, 22:02
	Хо! В яндексе ещё надо знать какой вопрос задавать. А посему, ваши не нулевые параллельные запросы в мсиквеле разбиваются о блокировки, которые он при этом использует. Так что пользы от них на практике тотже 0. Вне зависимости какой у вас поисковик.:D
	Ответить \| Правка \| ^ к родителю #35 \| Наверх \| Cообщить модератору


	47. "Релиз СУБД PostgreSQL 9.2"	+/–
	Сообщение от Andrey Mitrofanov on 12-Сен-12, 22:39
	> Блин, а ктонить в курсе, полное задействование проца (всех ядер) для одного > запроса, т.е. его распараллеливание, когданить сделают? или это для постгреса не > реально? Чего конкретно http://www.postgresql.org/docs/9.1/static/geqo-intro.html не хватает? Какие http://www.postgresql.org/docs/7.1/static/geqo.html#GEQO-INTRO слова не понятны?
	Ответить \| Правка \| ^ к родителю #3 \| Наверх \| Cообщить модератору


	49. "Релиз СУБД PostgreSQL 9.2"	–1 +/–
	Сообщение от Аноним (??) on 13-Сен-12, 01:15
	Понятно что параллелить построение плана сложно, но когда он построен, почему бы не распараллелить его исполнение? В простейшем случае если известно что придется просмотреть определенный диапазон строк, то почему бы не разделить его на поддиапазоны и не натравить на каждый отдельное ядро?
	Ответить \| Правка \| ^ к родителю #47 \| Наверх \| Cообщить модератору


	48. "Релиз СУБД PostgreSQL 9.2"	+/–
	Сообщение от XoRe (ok) on 12-Сен-12, 23:34
	> Блин, а ктонить в курсе, полное задействование проца (всех ядер) для одного > запроса, т.е. его распараллеливание, когданить сделают? или это для постгреса не > реально? Когда у вас будет 10-100 одновременных запросов к БД и будут загружены даже 24 ядра, вы поймете, что 1 запрос на ядро - это благо) Лучше запрос одним ядром обрабатывается и не тратит время на переключения ядер. А если у вас 1-2 одновременных запроса к БД, нужно менять логику работы с БД, если хотите параллелить. Самым узким местом должен быть жесткий. Если узкое место в чем-то другом, значит, есть место для оптимизации)
	Ответить \| Правка \| ^ к родителю #3 \| Наверх \| Cообщить модератору