| |
| 2.14, rshadow (ok), 15:13, 12/11/2015 [^] [^^] [^^^] [ответить]
| +3 +/– |
 Согласен. Но за фильтрацию без индексов в продакшене надо руки отрывать =), а не запросы параллелить.
| | |
| |
| 3.17, КО (?), 16:40, 12/11/2015 [^] [^^] [^^^] [ответить]
| +1 +/– |
Ну нормальный индекс для примера из шапки в студию.
Ну и чтоб вместо '%a%' - bind.
| | |
| 3.22, rob pike (?), 18:29, 12/11/2015 [^] [^^] [^^^] [ответить]
| –3 +/– |
Во-первых, читайте внимательней.
> Parallel query for PostgreSQL - for which this is the first step
Во-вторых, если соотношение insert и select 100500 к одному-раз-в-месяц-по-ночам, то отрывать надо за индексы.
| | |
| |
| 4.23, rshadow (ok), 18:54, 12/11/2015 [^] [^^] [^^^] [ответить]
| –2 +/– |
По всей видимости вам уже нужна не БД :) А за хранение логов в БД, руки тоже надо отрывать.
| | |
| |
| 5.31, all_glory_to_the_hypnotoad (ok), 00:14, 13/11/2015 [^] [^^] [^^^] [ответить]
| +/– |
 > По всей видимости вам уже нужна не БД :) А за хранение логов в БД, руки тоже надо отрывать.
молчал бы уже коли нихрена не разбираешься в сути вопроса.
| | |
|
| 4.34, anonymous (??), 07:36, 13/11/2015 [^] [^^] [^^^] [ответить]
| +/– |
BTREE плохо подходят для больших баз с write-only нагрузкой.
Cмысл писать такие коменты в теме с PostgreSQL? он же не умеет в LSM
| | |
| |
| 5.37, rob pike (?), 08:26, 13/11/2015 [^] [^^] [^^^] [ответить]
| +/– | |
> BTREE плохо подходят для больших баз с write-only нагрузкой.
В случае B-tree всё намного больше определяется конкретной имплементацией чем кажется. Для начала можете посмотреть на LMDB.
> он же не умеет в LSM
Очень хорошо что не умеет. Не приходится ходить покурить пока у него compacting.
| | |
|
|
| 3.43, Аноним (-), 10:35, 13/11/2015 [^] [^^] [^^^] [ответить]
| –1 +/– |
> Согласен. Но за фильтрацию без индексов в продакшене надо руки отрывать =),
> а не запросы параллелить.
OLTP vs DWH ;)
| | |
|
|
| |
| |
| |
| 4.52, Аноним (-), 21:48, 14/11/2015 [^] [^^] [^^^] [ответить]
| +/– |
Нет, именно так: "А вам, что, MySQL лучше Postgres? Зачем Вы гнусите то?"
Разговор про один уровень. БЕсплатное, доступное и оооочень даже Advanced. Если уж на то пошло то и Postgres изменяют и делают коммерческим, и функции этих систем, уж совсем недалеко от "крыши" технологий, тут вот с Оракл 9 и сравнивать уже можно.
| | |
|
| |
| 4.24, Аноним (-), 20:11, 12/11/2015 [^] [^^] [^^^] [ответить]
| –1 +/– |
"Гнусите-то", позорище.
Ты же понимашь, что пипл просто пишет как быстрее, чтоб не париться. Так делаешь и ты, но при этом всех оскорбляешь.
| | |
|
|
| 2.15, rshadow (ok), 15:15, 12/11/2015 [^] [^^] [^^^] [ответить]
| +4 +/– |
Думаю лет через пять, такими темпами, перегонять уже будет некого. Как говориться: "Если нет разницы, зачем платить больше?" (с)
| | |
| |
| |
| 4.26, Вареник (?), 21:20, 12/11/2015 [^] [^^] [^^^] [ответить]
| +/– |
Именно. Где еще взять такую возможность освоить бюджет. Это даже лучше чем латать один любимый участок дороги каждую неделю, высыпая асфальт на снег и лужи.
| | |
| 4.44, rshadow (ok), 11:47, 13/11/2015 [^] [^^] [^^^] [ответить]
| –1 +/– |
Как показывает практика деньги пилятся вне зависимости от стоимости ПО, и в не меньших объемах. Просто с Ораклом обосновывать легче.
| | |
|
| 3.46, Танцпольный наймит Госдепа (?), 17:07, 13/11/2015 [^] [^^] [^^^] [ответить]
| +/– | |
> Думаю лет через пять, такими темпами, перегонять уже будет некого. Как говориться: "Если нет разницы, зачем платить больше?" (с)
Основной заказчик ПО Оракл — государственный департамент США. Вряд ли за пять лет США кончатся, если вы понимаете о чём я. Но здравый смысл в ваших словах есть, конечно.
| | |
|
|
| 1.11, Аноним (-), 13:50, 12/11/2015 [ответить] [﹢﹢﹢] [ · · · ]
| –1 +/– |
Только вот непонятно, почему degree общий на весь запрос, и почему нельзя было сделать хинтом как в Oracle, не думаю что там патенты мешают ...
| | |
| |
| |
| 3.13, Аноним (-), 15:02, 12/11/2015 [^] [^^] [^^^] [ответить]
| +/– | |
Только из того "что-плохого" многое после реальной работы с большими и тяжёлыми запросами на серьёзном оборудовании кажется надуманным.
Большой плюс хинтов в том что для сложных запросов можно достаточно простым способом настроить предсказуемое поведение ( хотя Oracle иногда ведёт себя не так как ему указывают, но это в основном из-за недостатка ресурсов ).
Как настроить сложный запрос с помощью предварительных директив не очень понятно, как пример сложный запрос с объединением фильтрованных данных из нескольких таблиц, как ограничивать degree?
| | |
| |
| |
| 5.41, Аноним (-), 10:20, 13/11/2015 [^] [^^] [^^^] [ответить]
| +/– | |
> Что за degree? О чём Вы?
rhaas=# set max_parallel_degree = 4;
SET
Time: 0.270 ms
rhaas=# select * from pgbench_accounts where filler like '%a%';
aid | bid | abalance | filler
-----+-----+----------+--------
(0 rows)
Time: 213.412 ms
| | |
|
| 4.21, rob pike (?), 18:25, 12/11/2015 [^] [^^] [^^^] [ответить]
| –1 +/– | |
> There is a philosophical difference between PostgreSQL’s approach and that of many other systems. In PostgreSQL, it is encouraged to specify costs and selectivities more than exact plans. There are good reasons for that, such as sheer number of possible plans for even moderately complex queries. Additionally, specifying exact plans tends to lead you into exactly the type of trouble you are trying to avoid by specifying hints in the first place — after input cardinalities change, the previous plan may now be a very poor one. | | |
| |
| 5.40, Аноним (-), 10:18, 13/11/2015 [^] [^^] [^^^] [ответить] | +/– | Это понятно что криворуких, не понимающих что тестовая база в 10 Гб и рабочая в... большой текст свёрнут, показать | | |
| |
| 6.45, rob pike (?), 17:06, 13/11/2015 [^] [^^] [^^^] [ответить]
| +4 +/– | |
> эти грабли всё-таки в головах
Это значит что эти грабли - будут всегда, у подавляющего большинства пользователей, и с ними ничего не сделаешь.
> хинты - удобный способ делать что-то быстро
А потом, когда это временное "быстро" превратится в долгосрочное "медленно", все интернеты будут полны "ваш PostgreSQL - тормоз". Спасибо, не надо, цель разработчиков PostgreSQL не в том чтобы всех подсадить на платиновый саппорт.
| | |
|
|
| 4.29, АнониМ (ok), 23:05, 12/11/2015 [^] [^^] [^^^] [ответить]
| +/– |
 >Большой плюс хинтов в том что для сложных запросов можно достаточно простым способом настроить предсказуемое поведение
хинты это рекомендации для оракла, соответственно никакого предсказуемого поведения нет, а есть лишь иллюзии. особенно прикольно, когда после нового сбора статистики, оракл плюёт на все хинты и начинает стоить декартово произведение таблиц с уходом времени выполнения в бесконечность.
| | |
| |
| 5.39, Аноним (-), 10:15, 13/11/2015 [^] [^^] [^^^] [ответить]
| +/– |
>>Большой плюс хинтов в том что для сложных запросов можно достаточно простым способом настроить предсказуемое поведение
> хинты это рекомендации для оракла, соответственно никакого предсказуемого поведения нет,
> а есть лишь иллюзии. особенно прикольно, когда после нового сбора статистики,
> оракл плюёт на все хинты и начинает стоить декартово произведение таблиц
> с уходом времени выполнения в бесконечность.
Статистика отключаема, и отключается именно по этой причине, план можно прибить гвоздями и в Oracle...
| | |
|
|
|
| 2.32, all_glory_to_the_hypnotoad (ok), 00:18, 13/11/2015 [^] [^^] [^^^] [ответить]
| +/– | |
> Только вот непонятно, почему degree общий на весь запрос...
вообще и его быть не должно, должна быть глобальная опция настройки сервера. Потом мб так и будет.
| | |
| |
| 3.42, Аноним (-), 10:21, 13/11/2015 [^] [^^] [^^^] [ответить]
| +/– |
>> Только вот непонятно, почему degree общий на весь запрос...
> вообще и его быть не должно, должна быть глобальная опция настройки сервера.
> Потом мб так и будет.
и что с конкуренцией запросов, кому сколько давать? ядер и 200 может быть...
| | |
| |
| 4.47, all_glory_to_the_hypnotoad (ok), 22:06, 13/11/2015 [^] [^^] [^^^] [ответить]
| +/– | |
Очевидно, это видно планировщику запроса исходя из оценочного объёма данных, расположению их по дискам и квотам пользователя если таковые имеются.
> и что с конкуренцией запросов, кому сколько давать? ядер и 200 может быть...
их может быть и сотни тыс. (например, mapreduce кластер). Здесь почти типичная mr задача.
| | |
|
|
|
| 1.25, Аноним (-), 20:42, 12/11/2015 [ответить] [﹢﹢﹢] [ · · · ]
| –3 +/– |
Так в мускуле есть партицирование таблиц, где по идее происходит тоже самое. При запросе оно выполняет отдельным потоком подзапрос по каждой партиции. Или я ошибаюсь?
| | |
| |
| 2.33, all_glory_to_the_hypnotoad (ok), 00:27, 13/11/2015 [^] [^^] [^^^] [ответить]
| +/– | |
> Так в мускуле есть партицирование таблиц, где по идее происходит тоже самое.
нет, это просто способ разбиения данных на куски для других целей. Настоящее распараллеливание работает на любой таблице.
> При запросе оно выполняет отдельным потоком подзапрос по каждой партиции. Или я ошибаюсь?
Вроде ошибаешься, есть какие-то внешние костыли с помощью которых можно шардить запрос по партициям.
| | |
|
| 1.30, АнониМ (ok), 23:07, 12/11/2015 [ответить] [﹢﹢﹢] [ · · · ]
| –1 +/– |
А какая цена по памяти всего этого счастья. в оракле параллельные запросы очень не прилично по памяти себя ведут к примеру.
| | |
| |
| 2.36, anonymous (??), 07:44, 13/11/2015 [^] [^^] [^^^] [ответить]
| +/– | |
> А какая цена по памяти всего этого счастья
Для full table scan это равнозначно нескольким параллельным запросам над 1/4-1/10 таблицы, другое дело, что процессоры это будет жрать как не в себя и тупить приложение будет не только у одного клиента, как без паралельного выполнения запросов, а у всех клиентов.
| | |
| |
| 3.38, Alex (??), 09:38, 13/11/2015 [^] [^^] [^^^] [ответить]
| +/– |
Особенно эротично это будет выглядеть на HDD-based базе объёмом больше, чем выделенная под буфер память.
| | |
|
|
| 1.35, anonymous (??), 07:39, 13/11/2015 [ответить] [﹢﹢﹢] [ · · · ]
| +/– | |
Пример select * from pgbench_accounts where filler like '%a%' идиотский, full text search в каком-нидь sphinx будет бодрее чем новая реализация.
Но, это хороший задел для распаралеливания full table scan'ов на несколько узлов с шардингом (которые обещают в следующие лет 5).
| | |
| |
| 2.50, Aleks Revo (ok), 15:54, 14/11/2015 [^] [^^] [^^^] [ответить]
| +/– |
 А при чём тут вообще full text? был дан пример неиндексируемого в обычных условиях запроса для демнстрации разницы производительности - не более того. А там - что угодно можно анализировать, хоть generate_series, главное, что это теперь МОЖЕТ параллелиться, а не цедится в один поток.
Как итог: транзакции быстрее завершаются, сокращается число потенциальных блокировок и все следующие из этого плюшки.
| | |
|
|
