Добро пожаловать в форум, Guest >> Войти | Регистрация | Поиск | Правила | | В избранное | Подписаться | ||
Все форумы / PostgreSQL |
![]() ![]() |
Топик располагается на нескольких страницах: ←Ctrl назад 1 2 3 4 [5] 6 7 вперед Ctrl→ все |
p2. Member Откуда: Сообщений: 526 |
model что-то вроде расчетов excel-листа. Вещь достаточно специфичная и трудновоспринимаемая в реляционных реалиях, к тому же, не имеет нормальной относительной адресации ячеек, что иногда требует замешивания с аналитическими row_number() over(). Появилась еще в 10г, но на практике крайне редко применяемая. Разве что для замены with-рекурсии, появившейся в более поздней версии (древнеоракловая connect by-рекурсия не позволяет работать с накопительными счетчиками). Функционал model можно процедурно выразить pipelined-функциями, но в оракле переключение plsql-контекста очень дорого и реализация функцией более громоздка, так как требует отдельного создания объектного и табличного типов. Полагаю, что для postgresql реализация функцией будет достаточно эффективной, чтобы не заморачиваться с экзотикой model. Хотя тут тогда хотелось бы иметь возможность применять with-function непосредственно в запросе, то есть без создания хранимки. Описание model http://docs.oracle.com/database/121/DWHSG/sqlmodel.htm В оракле 12ц появилась более достойная реализации фича match_recognize, позволяющая оперировать последовательностью упорядоченных данных. Заменяет многовложенные подзапросы с оконными функциями на более лаконичные и формализованные на более подходящем для описания серий данных языке паттернов, накопительных показателей и агрегатов. Типичное применениe - выделение пиков/спадов/подъемов и прочих групп в серии. Такого рода аналитика ближе по духу к реляционным СУБД и потребность в ней возникает почаще modelных inter-row calculations. Описание http://docs.oracle.com/database/121/DWHSG/pattern.htm Примеры задач на sql.ru: Сброс суммы при превышении порога 17674425 Периоды положительного баланса 15515818 Маршрут из точки А в точку Б 15981735 |
20 авг 15, 16:35 [18047011] Ответить | Цитировать Сообщить модератору |
Legushka Member Откуда: Казань Сообщений: 630 |
не хватает условий в оконных функциях. |
18 дек 15, 15:53 [18579046] Ответить | Цитировать Сообщить модератору |
Ivan Durak Member Откуда: Minsk!!! Сообщений: 3646 |
например? |
||
18 дек 15, 15:54 [18579064] Ответить | Цитировать Сообщить модератору |
Lonepsycho Member Откуда: Siauliai, Литва Сообщений: 588 |
чего мне нехватает, так планера который бы учитывал FOREIGN KEY как CONSTRAINT при создании планов для запросов. например для запросов которые идут на таблицы с наследниками. |
18 дек 15, 16:51 [18579478] Ответить | Цитировать Сообщить модератору |
qwwq Member Откуда: Сообщений: 2894 |
читаю http://habrahabr.ru/post/274659/ BRIN-индексы когда--то пытался понять, ускорит ли такое индексирование поля xmin [напр -- по условию where xmin <>2] вакуумирование "to prevent wrapparrond" больших баз, большая часть которых архивна, а в меньшей идёт активная жизнь. навскидку казалось, что должно. и существенно. (сейчас оно периодически молотит старые таблицы неделями). нет ? |
12 янв 16, 17:07 [18668265] Ответить | Цитировать Сообщить модератору |
Павел Лузанов Member Откуда: Сообщений: 770 |
qwwq, Хитро заходишь. Узнаешь ответ - поделись. |
13 янв 16, 14:08 [18672705] Ответить | Цитировать Сообщить модератору |
qwwq Member Откуда: Сообщений: 2894 |
Павел Лузанов, кто из нас двоих работает в я от вас хотел узнать, не приделали ли подобную БРИНУ штуковину к прокрутке frize-уемых объектов на предмет необходимости выставления в 2-ку. Чтобы значит целые блоки можно было не читать. кажется что именно отсюда должна была родиться идея БРИН, а не наоборот. уж очень оно на больших активно пишущих (в малую часть) базах накладно -- всё растущую базу на предмет фриза всё время прокручивать. |
13 янв 16, 14:31 [18672854] Ответить | Цитировать Сообщить модератору |
Павел Лузанов Member Откуда: Сообщений: 770 |
Не сомневаюсь, что не приделали. А вот может ли помочь - это надо посмотреть. |
||
13 янв 16, 18:22 [18674416] Ответить | Цитировать Сообщить модератору |
PCContra Member Откуда: Торжок, Тверская область, Россия Сообщений: 302 |
Postgres пока (версия 9.5) не умеет сравнивать тип данных JSON друг с другом ЖДУ. |
28 янв 16, 13:10 [18739903] Ответить | Цитировать Сообщить модератору |
Maxim Boguk Member Откуда: Melbourne, Австралия Сообщений: 4581 |
В эту сторону смотрят активно: http://www.postgresql.org/message-id/flat/CAD21AoDOc-m0WQiJjEjYKkUhF8S8VDg06G6cFqjSBz1R1LEMQw@mail.gmail.com#CAD21AoDOc-m0WQiJjEjYKkUhF8S8VDg06G6cFqjSBz1R1LEMQw@mail.gmail.com Весьма вероятно что в 9.5 это войдет (во всяком случае я на это надеюсь). -- Maxim Boguk www.postgresql-consulting.ru |
||
28 янв 16, 13:55 [18740234] Ответить | Цитировать Сообщить модератору |
Maxim Boguk Member Откуда: Melbourne, Австралия Сообщений: 4581 |
Если вам по строго равенству то ::text = ::text вас вполне спасет. Или вы что то другое имеете в виду? |
||
28 янв 16, 13:56 [18740242] Ответить | Цитировать Сообщить модератору |
qwwq Member Откуда: Сообщений: 2894 |
а вот hstore хотя бы всегда упорядочивает пары по ключам. т.е. там это был бы правильный финт ушами. А в жейсоне в 9.4 не похоже чтобы в узлах хотя бы по ключам упорядочивало. м.б. в jsonb оно как--то лучшее чуть ? короче -- тьху на него три раза. и популейтит он через раз. и сравнения на нём кривые. и вообще. |
||||
28 янв 16, 14:44 [18740606] Ответить | Цитировать Сообщить модератору |
Misha Tyurin Member Откуда: Тюмень Сообщений: 2243 |
Максим, в 95 точно не вошло уже. может в 97... |
||
29 янв 16, 15:14 [18745976] Ответить | Цитировать Сообщить модератору |
ОКТОГЕН Member Откуда: Сообщений: 2494 |
В pg есть двоичный формат резервной копии. Реально не хватает возможности просмотра дампа вовнутрь 1)Просмотра списка объектов и их структуры 2)Возможности просмотра данных таблиц, и/или экспорта этих данных в CSV/SQL |
9 фев 16, 10:27 [18791465] Ответить | Цитировать Сообщить модератору |
Maxim Boguk Member Откуда: Melbourne, Австралия Сообщений: 4581 |
Вы о: ? |
||
9 фев 16, 10:35 [18791496] Ответить | Цитировать Сообщить модератору |
Павел Лузанов Member Откуда: Сообщений: 770 |
Приделали карту заморозки страниц, в которую смотрит vacuum. В 9.6 будет. |
||||
11 мар 16, 10:32 [18918693] Ответить | Цитировать Сообщить модератору |
qwwq Member Откуда: Сообщений: 2894 |
а чо, уважаемые, будут ли нормальные "родные" автономии в plpgsql , чтобы ,значит, в дереве локов всё, и дедлоки снимались?
|
|
31 мар 16, 17:01 [19001320] Ответить | Цитировать Сообщить модератору |
Серджио Member Откуда: Сообщений: 15 |
Было бы неплохо использовать подзапросы в CHECK |
14 май 16, 18:21 [19173273] Ответить | Цитировать Сообщить модератору |
Локшин Марк Member Откуда: Воронеж Сообщений: 3155 |
Серджио, Триггер напиши, и будет нужный функционал. Вообще в каких-то СУБД в CHECK можно писать подзапрос? |
14 май 16, 19:28 [19173371] Ответить | Цитировать Сообщить модератору |
p2. Member Откуда: Сообщений: 526 |
|
||
14 май 16, 22:04 [19173819] Ответить | Цитировать Сообщить модератору |
qwwq Member Откуда: Сообщений: 2894 |
"возвращаясь к напечатанному" появилась статейка ПгП. https://habrahabr.ru/company/postgrespro/blog/301238/ ++: 1 полезна как пальцевая для админов, борющихся с фризом 2. кажется будет ещё одна припарка незначительная (см в тексте про тхид самого факьюма) -- думаю -- пустое. но и статья пустовата --: 1. не затронута разница read only и пишущих 2. выпал из внимания момент, когда именно транза получает тхид (становится пишущей) 3. ничего не сказано о номерах "сабтранзакций" (рост xmin за сейвпойнтами == в блоках исключений) -- т.е. выпадает из понимания полезность новых фичь, позволяющих делать то же, что раньше, но без блоков обработки (того же мерджа). -- а это уже важно для кодеров --если у вас данное приходит пачками по 1000/транзакцию, и каждое -- обрабатывается в хранимке (or триггере) в блоке исключения -- у вас счётчик вырастет на 1000. если же вам удастся вытеснить блок на задворки -- только для редких случаев -- счетчик, за весь пакет, возрастет всего на законную единичку -- сейвпойнтов--то нет. ну и т.п. но для админов, в качестве пальцевой иллюстрации самого механизма -- очень пользительно, я щетаю. т.ч. рекомендую. |
||||
20 май 16, 12:55 [19197872] Ответить | Цитировать Сообщить модератору |
Павел Лузанов Member Откуда: Сообщений: 770 |
Про это есть в теме 3 "Страницы и версии строк": http://www.postgrespro.ru/education/courses/DBA2 Там можно презентацию и видео найти. Конструктивная критика будет очень полезна. |
||
20 май 16, 20:00 [19200367] Ответить | Цитировать Сообщить модератору |
Насяльника Member Откуда: Сообщений: 436 |
CLUSTER |
14 окт 16, 13:58 [19781705] Ответить | Цитировать Сообщить модератору |
vyegorov Member Откуда: Баньоло-ин-Пьяно Сообщений: 1227 |
Это? (Третий пункт в списке.) |
||
27 окт 16, 23:24 [19831147] Ответить | Цитировать Сообщить модератору |
Lonepsycho Member Откуда: Siauliai, Литва Сообщений: 588 |
похоже, что на это намекают. будем тестировать, посмотрим. интересно какой план будет построен. |
||||
28 окт 16, 12:14 [19832823] Ответить | Цитировать Сообщить модератору |
Топик располагается на нескольких страницах: ←Ctrl назад 1 2 3 4 [5] 6 7 вперед Ctrl→ все |
Все форумы / PostgreSQL | ![]() |