Добро пожаловать в форум, Guest  >>   Войти | Регистрация | Поиск | Правила | В избранное | Подписаться
Все форумы / PostgreSQL Новый топик    Ответить
Топик располагается на нескольких страницах: 1 2 3 4 5 6      [все]
 Голосуем за новые фичи PG  [new]
web_fox
Member

Откуда: Киев
Сообщений: 444
Голосовать здесь

или предлагаем свои
Модератор: Ссылка переехала...
13 янв 11, 22:11    [10069172]     Ответить | Цитировать Сообщить модератору
 Re: Голосуем за новые фичи PG  [new]
ОКТОГЕН
Member

Откуда:
Сообщений: 2479
1)Было бы неплохо, если бы INSERT/UPDATE/DELETE ... RETURNING <fields>
позволял использовать эти данные более наглядно, что ли.
Как, например, запихнуть удалённые айдишники во временную таблицу?
2)Было бы круто, если бы разрабы обновляли интерфейсы доступа к СУБД из языков в соответствии с фичами СУБД,
а то регулярно на косяки напарываемся.
3)Допиливание формата двоичного дампа, чтобы он был совместим между платформами и обратно совместим между версиями.
14 янв 11, 19:12    [10075087]     Ответить | Цитировать Сообщить модератору
 Re: Голосуем за новые фичи PG  [new]
ОКТОГЕН
Member

Откуда:
Сообщений: 2479
Да, MERGE нужен по-любому, index-only-scans желательно
14 янв 11, 19:15    [10075096]     Ответить | Цитировать Сообщить модератору
 Re: Голосуем за новые фичи PG  [new]
tanglir
Member

Откуда:
Сообщений: 30154
Во, аццы, расскажите, а матвью в постгре уже есть? А то Ёу говорит, что есть, а вот я не верю.
14 янв 11, 19:26    [10075145]     Ответить | Цитировать Сообщить модератору
 Re: Голосуем за новые фичи PG  [new]
Warstone
Member

Откуда:
Сообщений: 4896
Блог
Есть, но через жопу. Так пойдет?
14 янв 11, 20:18    [10075327]     Ответить | Цитировать Сообщить модератору
 Re: Голосуем за новые фичи PG  [new]
tanglir
Member

Откуда:
Сообщений: 30154
Warstone
Есть, но через жопу. Так пойдет?
пойдёт :)
14 янв 11, 20:39    [10075384]     Ответить | Цитировать Сообщить модератору
 Re: Голосуем за новые фичи PG  [new]
Weed
Member

Откуда:
Сообщений: 604
Возможность указывать алиас таблицы в INSERT как в UPDATE и SELECT, например:

INSERT INTO tablitsa t (a,b,c) VALUES (1,2,3) RETURNING t.a, t.b, t.c;
16 янв 11, 12:02    [10079576]     Ответить | Цитировать Сообщить модератору
 Re: Голосуем за новые фичи PG  [new]
Weed
Member

Откуда:
Сообщений: 604
математическая функция hypot(x, y)
Она есть в C math.h, очень удобно в геометрии юзать, ошибка меньше накапливается чем если через теорему Пифагора считать.
16 янв 11, 12:03    [10079581]     Ответить | Цитировать Сообщить модератору
 Re: Голосуем за новые фичи PG  [new]
Asm64D
Member

Откуда: [Краснодар] http://cluboflosers13.livejournal.com/
Сообщений: 6477
А я голосовал за "pl/sql packages (like Oracle)", считаю очень нужной вещью.
16 янв 11, 14:06    [10079830]     Ответить | Цитировать Сообщить модератору
 Re: Голосуем за новые фичи PG  [new]
Warstone
Member

Откуда:
Сообщений: 4896
Блог
Weed
математическая функция hypot(x, y)
Она есть в C math.h, очень удобно в геометрии юзать, ошибка меньше накапливается чем если через теорему Пифагора считать.
Что мешает подключить как хранимку?
16 янв 11, 15:01    [10079926]     Ответить | Цитировать Сообщить модератору
 Re: Голосуем за новые фичи PG  [new]
Росгоснанораспилтрест
Guest
Weed
математическая функция hypot(x, y)
Она есть в C math.h, очень удобно в геометрии юзать, ошибка меньше накапливается чем если через теорему Пифагора считать.


Так если есть - добавить её в Слона нет никакого труда. Пишешь свой C Extension - и всё отлично. Пишутся они очень легко, если хоть чуть-чуть знаешь С.
16 янв 11, 18:18    [10080386]     Ответить | Цитировать Сообщить модератору
 Re: Голосуем за новые фичи PG  [new]
Росгоснанораспилтрест
Guest
А дальше можешь в Contrib пропихнуть...
16 янв 11, 18:23    [10080395]     Ответить | Цитировать Сообщить модератору
 Re: Голосуем за новые фичи PG  [new]
web_fox
Member

Откуда: Киев
Сообщений: 444
Народ, только желаемые фичи не сюда надо писать, а по ссылке. Чтобы заказать свою фичу должен быть один свободный бал.
16 янв 11, 18:39    [10080432]     Ответить | Цитировать Сообщить модератору
 Re: Голосуем за новые фичи PG  [new]
ОКТОГЕН
Member

Откуда:
Сообщений: 2479
web_fox, проголосовал за:
index-only-scans - 1 голос
merge-upsert-replace - 3 голоса
better-administration-and-monitoring-tools - 3 голоса
add-deferred-option-to-check-constraints - 3 голоса
Первые две вещи явно назрели,
админ-приспособ много не бывает,
с необходимостью отложенных check-ов сталкивался, пришлось обходить с геморроем.
17 янв 11, 11:07    [10082952]     Ответить | Цитировать Сообщить модератору
 Re: Голосуем за новые фичи PG  [new]
Misha Tyurin
Member

Откуда: Тюмень
Сообщений: 2236
ОКТОГЕН,

add-deferred-option-to-check-constraints - http://www.postgresql.org/docs/current/static/sql-set-constraints.html

ну вот так-то можно же уже. то что надо.
17 янв 11, 20:03    [10087041]     Ответить | Цитировать Сообщить модератору
 Re: Голосуем за новые фичи PG  [new]
Misha Tyurin
Member

Откуда: Тюмень
Сообщений: 2236
http://wiki.postgresql.org/wiki/Index-only_scans - вот это реально интересно
17 янв 11, 21:50    [10087396]     Ответить | Цитировать Сообщить модератору
 Re: Голосуем за новые фичи PG  [new]
ОКТОГЕН
Member

Откуда:
Сообщений: 2479
Misha Tyurin, Я имел в виду не ключи уникальности и не внешние ключи,
а именно CHECK (проверки) отложенные.
В 8.4 таких нет.
17 янв 11, 23:25    [10087637]     Ответить | Цитировать Сообщить модератору
 Re: Голосуем за новые фичи PG  [new]
Misha Tyurin
Member

Откуда: Тюмень
Сообщений: 2236
ОКТОГЕН,

точно нету, надо значит)
17 янв 11, 23:34    [10087649]     Ответить | Цитировать Сообщить модератору
 Re: Голосуем за новые фичи PG  [new]
Misha Tyurin
Member

Откуда: Тюмень
Сообщений: 2236
Misha Tyurin,

но в самом общем виде есть теперь у нас вот такая штука http://www.postgresql.org/docs/9.0/static/sql-createconstraint.html и во там уже

DEFERRABLE
NOT DEFERRABLE
INITIALLY IMMEDIATE
INITIALLY DEFERRED

что не отменяет желания проверять обычные нотнулы и чеки в конце транзакций, всё верно
17 янв 11, 23:37    [10087658]     Ответить | Цитировать Сообщить модератору
 Re: Голосуем за новые фичи PG  [new]
ОКТОГЕН
Member

Откуда:
Сообщений: 2479
Misha Tyurin, Достаточно чеков, нот нул несложно эмулировать с их помощью,
но лучше, конечно, чтоб всё по-уму было, а не как у некоторых.
18 янв 11, 12:26    [10089732]     Ответить | Цитировать Сообщить модератору
 Re: Голосуем за новые фичи PG  [new]
Misha Tyurin
Member

Откуда: Тюмень
Сообщений: 2236
http://wiki.postgresql.org/wiki/Table_partitioning - вот еще полезное дело, на мой взгляд, затеяли
18 янв 11, 14:06    [10090772]     Ответить | Цитировать Сообщить модератору
 Re: Голосуем за новые фичи PG  [new]
Misha Tyurin
Member

Откуда: Тюмень
Сообщений: 2236
ОКТОГЕН,

автор
1)Было бы неплохо, если бы INSERT/UPDATE/DELETE ... RETURNING <fields>
позволял использовать эти данные более наглядно, что ли.
Как, например, запихнуть удалённые айдишники во временную таблицу?

кстати, похоже что в 9.1 можно будет returning в cte юзать

http://archives.postgresql.org/pgsql-hackers/2011-01/msg01307.php
18 янв 11, 15:04    [10091226]     Ответить | Цитировать Сообщить модератору
 Re: Голосуем за новые фичи PG  [new]
ОКТОГЕН
Member

Откуда:
Сообщений: 2479
Misha Tyurin, да, сча оне ещё глобальные времянки допилят.
Во конкурентище-то растёт.
18 янв 11, 15:18    [10091356]     Ответить | Цитировать Сообщить модератору
 Re: Голосуем за новые фичи PG  [new]
Misha Tyurin
Member

Откуда: Тюмень
Сообщений: 2236
ОКТОГЕН,

ситуация накаляется)
18 янв 11, 15:30    [10091466]     Ответить | Цитировать Сообщить модератору
 Re: Голосуем за новые фичи PG  [new]
Andron
Member

Откуда: Cherepovets
Сообщений: 1816
Там есть вкладка "Completed ideas", это что, уже реализованные идеи? Например inplace upgrades с одной версии на другую без dump/restore уже работает?
19 янв 11, 09:01    [10094462]     Ответить | Цитировать Сообщить модератору
 Re: Голосуем за новые фичи PG  [new]
Warstone
Member

Откуда:
Сообщений: 4896
Блог
Andron,

через pg_migrator. Но он еще сложный.
19 янв 11, 11:13    [10095140]     Ответить | Цитировать Сообщить модератору
 Re: Голосуем за новые фичи PG  [new]
Misha Tyurin
Member

Откуда: Тюмень
Сообщений: 2236
Andron,

http://www.postgresql.org/docs/9.0/static/pgupgrade.html

---

но потом полный аналайз нужен)
19 янв 11, 11:48    [10095432]     Ответить | Цитировать Сообщить модератору
 Re: Голосуем за новые фичи PG  [new]
Weed
Member

Откуда:
Сообщений: 604
Weed
Возможность указывать алиас таблицы в INSERT как в UPDATE и SELECT, например:

INSERT INTO tablitsa t (a,b,c) VALUES (1,2,3) RETURNING t.a, t.b, t.c;


Таки закатайте пожалуйста туда вот эту фичу? Это чистая косметика но она очень облегчает жизнь при написании рулесов.

У меня нету "баллов" или как их там, я вообще о сборе реквестов только от вас узнал.
19 янв 11, 15:29    [10097457]     Ответить | Цитировать Сообщить модератору
 Re: Голосуем за новые фичи PG  [new]
Weed
Member

Откуда:
Сообщений: 604
Росгоснанораспилтрест
Weed
математическая функция hypot(x, y)
Она есть в C math.h, очень удобно в геометрии юзать, ошибка меньше накапливается чем если через теорему Пифагора считать.


Так если есть - добавить её в Слона нет никакого труда. Пишешь свой C Extension - и всё отлично. Пишутся они очень легко, если хоть чуть-чуть знаешь С.


Там какой-то математический фокус используется. То есть, она не использует теорему Пифагора а делает этот поиск как-то проще. Я не силён в математике.

И нельзя ведь Сишную hypot() использовать, numeric сильно точнее double
19 янв 11, 15:30    [10097479]     Ответить | Цитировать Сообщить модератору
 Re: Голосуем за новые фичи PG  [new]
web_fox
Member

Откуда: Киев
Сообщений: 444
Weed,

каждому персонально сразу даётся 10 балов и вам тоже :)

Нажимаете кнопочку VOTE напротив варианта, пишите меил какой-нить и имя и всё.
Давайте не ленитесь :)
19 янв 11, 17:35    [10098813]     Ответить | Цитировать Сообщить модератору
 Re: Голосуем за новые фичи PG  [new]
wbear
Member

Откуда: Москва
Сообщений: 374
хотелось бы что-то типа select ... with timeout '1 sec'; на запрос и глобальную/сессионную опцию лимитирующую время выполнения запроса на бекенде . Добавьте плз, а то с инглишем туго, боюсь опозориться :)
19 янв 11, 21:18    [10100116]     Ответить | Цитировать Сообщить модератору
 Re: Голосуем за новые фичи PG  [new]
ОКТОГЕН
Member

Откуда:
Сообщений: 2479
wbear, ,Уже есть триггер на вьюху.
Там можно писать полноценный код c NEW OLD полями
и языковыми конструкциями без извратов.
19 янв 11, 22:12    [10100272]     Ответить | Цитировать Сообщить модератору
 Re: Голосуем за новые фичи PG  [new]
ОКТОГЕН
Member

Откуда:
Сообщений: 2479
ОКТОГЕН
wbear, ,Уже есть триггер на вьюху.
Там можно писать полноценный код c NEW OLD полями
и языковыми конструкциями без извратов.

это weed-у
19 янв 11, 22:14    [10100281]     Ответить | Цитировать Сообщить модератору
 Re: Голосуем за новые фичи PG  [new]
Misha Tyurin
Member

Откуда: Тюмень
Сообщений: 2236
wbear,
автор
и глобальную/сессионную опцию лимитирующую время выполнения запроса на бекенде

statement_timeout - http://www.postgresql.org/docs/9.0/interactive/runtime-config-client.html

внимательнее надо к этим вопросам относиться
20 янв 11, 11:42    [10102426]     Ответить | Цитировать Сообщить модератору
 Re: Голосуем за новые фичи PG  [new]
Misha Tyurin
Member

Откуда: Тюмень
Сообщений: 2236
Misha Tyurin
wbear,
автор
и глобальную/сессионную опцию лимитирующую время выполнения запроса на бекенде

statement_timeout - http://www.postgresql.org/docs/9.0/interactive/runtime-config-client.html

внимательнее надо к этим вопросам относиться


я всякие таймауты контролирую на пгбоунсере http://pgbouncer.projects.postgresql.org/doc/config.html#_connection_sanity_checks_timeouts
20 янв 11, 12:05    [10102676]     Ответить | Цитировать Сообщить модератору
 Re: Голосуем за новые фичи PG  [new]
wbear
Member

Откуда: Москва
Сообщений: 374
ой ё, таки опозорился :) , зато пропала уверенность в том, что доки я читал внимательно. спасбо
20 янв 11, 12:43    [10103025]     Ответить | Цитировать Сообщить модератору
 Re: Голосуем за новые фичи PG  [new]
ОКТОГЕН
Member

Откуда:
Сообщений: 2479
wbear, уточню.
http://www.pgadmin.org/development/changelog.php
2010-11-07 GL 1.14.0 Add support for 9.1 new kind of trigger: INSTEAD OF.

Это относится к вьюхам.
Подробнее тут
20 янв 11, 14:17    [10103774]     Ответить | Цитировать Сообщить модератору
 Re: Голосуем за новые фичи PG  [new]
wbear
Member

Откуда: Москва
Сообщений: 374
ОКТОГЕН,

да уже, в подпись поставь себе
автор
это weed-у

:)
21 янв 11, 10:30    [10108045]     Ответить | Цитировать Сообщить модератору
 Re: Голосуем за новые фичи PG  [new]
Big Andy
Member

Откуда:
Сообщений: 425
Andron,

По крайней мере так заявлено. Я, например не рискнул. Даже для тестовой БД.
21 янв 11, 10:55    [10108361]     Ответить | Цитировать Сообщить модератору
 Re: Голосуем за новые фичи PG  [new]
Andron
Member

Откуда: Cherepovets
Сообщений: 1816
А скажите есть ли в PostgreSQL ограниченные режимы для базы? Например "административный" режим, допускающий работу только определенных пользователей с базой. Штука нужная думаю, и во многих базах она есть. Или например перевод в read-only режим, допускающий только чтение базы.
25 янв 11, 11:12    [10125742]     Ответить | Цитировать Сообщить модератору
 Re: Голосуем за новые фичи PG  [new]
ОКТОГЕН
Member

Откуда:
Сообщений: 2479
Andron,"административный" режим эмулируется подменой hba.conf
с соответствующими пользователями и reload-ом сервера.
Режим "только чтение", в частности, есть у slave-машин при репликации.
Надо просто перевести ПЖ в этот режим.
25 янв 11, 11:20    [10125826]     Ответить | Цитировать Сообщить модератору
 Re: Голосуем за новые фичи PG  [new]
Andron
Member

Откуда: Cherepovets
Сообщений: 1816
ОКТОГЕН,

это не то. Представьте - надо перестартовать сервер, менять конфиги. Неудобно. Было бы неплохо делать это без перезагрузки и одной командой.
25 янв 11, 11:34    [10125954]     Ответить | Цитировать Сообщить модератору
 Re: Голосуем за новые фичи PG  [new]
ОКТОГЕН
Member

Откуда:
Сообщений: 2479
Andron, reload это не рестарт.
Вы можете написать скрипт, который это делает.
25 янв 11, 11:47    [10126109]     Ответить | Цитировать Сообщить модератору
 Re: Голосуем за новые фичи PG  [new]
Игорь Куршаков
Member

Откуда:
Сообщений: 5
Забросил идею насчет виртуальных столбцов по аналогии с виртуальными функциями классов.

Пусть столбец декларируется в предке, а определяется в наследниках - всякий раз по-разному.
30 янв 11, 16:11    [10154951]     Ответить | Цитировать Сообщить модератору
 Re: Голосуем за новые фичи PG  [new]
Подпольщег
Guest
Игорь Куршаков, что-то торможу сильно.
Можно пару примеров, когда это реально полезно?
30 янв 11, 23:38    [10155967]     Ответить | Цитировать Сообщить модератору
 Re: Голосуем за новые фичи PG  [new]
Игорь Куршаков
Member

Откуда:
Сообщений: 5
Подпольщег
Игорь Куршаков, что-то торможу сильно.
Можно пару примеров, когда это реально полезно?


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

Суть идеи - чтоб доступ был к каким-то полям, которые определяются в наследнике как вычисляемые. Если есть запись от наследника, где поле не определено - то NULL.

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

Что касается примера, то [url=]http://www.sql.ru/forum/actualthread.aspx?tid=820849[/url]

В данном примере было иерархическое дерево с партицированием по типу узла. Благодаря тому, что все связи id-parent определяются на уровне предка, мы можем работать с деревом как с одной базой, хотя оно раскидано по таблицам типов узлов. Однако, для программы-клиента надо иметь строку с именем узла (чтоб построить дерево). А вот имя может быть разным, в зависимости от наследника. Имя вычисляемое, в зависимости от полей наследника.

И поскольку выборка из предка не дает нам полей наследников, то надо или делать дополнительный SELECT при выборке каждой записи дерева. Или делать поле-строку в предке и модифицировать ее триггерами, подвязанными к каждому наследнику.

В общем, или медленно или жирно.

Тогда как при реализованных виртуальных колонках можно было бы их задекларировать в предке, описать в наследнике и при запросах к предку сразу быстро вычислять и отдавать.
31 янв 11, 01:08    [10156115]     Ответить | Цитировать Сообщить модератору
 Re: Голосуем за новые фичи PG  [new]
Misha Tyurin
Member

Откуда: Тюмень
Сообщений: 2236
мне вот тут подумалось, что было бы очень не плохо иметь возможность в рамках кластера некоторые таблицы и/или индексы "принудительно" всегда держать в буферах.

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

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

как вам?
8 апр 11, 17:50    [10493115]     Ответить | Цитировать Сообщить модератору
 Re: Голосуем за новые фичи PG  [new]
tadmin
Member

Откуда:
Сообщений: 1181
Misha Tyurin
в рамках кластера некоторые таблицы и/или индексы "принудительно" всегда держать в буферах.

+1
Очень было бы полезно. Подчас разовый сервисный запрос выбивает кеш, хотя его время исполнения совершенно не критично.
Вроде бы Oracle позволяет подкручивать параметры кширования per object.Где-то слышал...
8 апр 11, 18:18    [10493248]     Ответить | Цитировать Сообщить модератору
 Re: Голосуем за новые фичи PG  [new]
Misha Tyurin
Member

Откуда: Тюмень
Сообщений: 2236
tadmin,

неее.... немного не то. вот как раз "разовый" запрос ничего не "выбивает", ибо там двухуровневый механизм. есть очередь ограниченной длинны первого уровня ("тёпленькое") и уже сами лру буфера на втором (то, что в "горячее" пролезло). вот тут это почитать в частности можно http://www.sai.msu.su/~megera/postgres/talks/what_is_postgresql.html - Управление буферами в PostgreSQL - там есть параграф.

вот если много "сервисных" подряд - то да, они могут перекосить распределение. (вот через это можно смотреть http://www.postgresql.org/docs/9.0/static/pgbuffercache.html)

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

и вот мы НЕ хотим НОВЫЙ кластер разворачивать, нам этот нравится, как всё там уже вокруг него классно сделано и всё на него настроено. но нам нужна новая фича, она требует чтобы небольшой быстрый индекс висел весь в памяти. запросы РЕДКИЕ и РЕНДОМНЫЕ к томуже по пробитию. но и требование, чтобы были максимально быстрыми всегда, без "прогревочного круга" - задача подстановок "налету".

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

так что вот, в чем у меня вопросы возникли.
8 апр 11, 20:04    [10493660]     Ответить | Цитировать Сообщить модератору
 Re: Голосуем за новые фичи PG  [new]
Warstone
Member

Откуда:
Сообщений: 4896
Блог
tmpfs с триггерным управлением не пробовали?
9 апр 11, 00:01    [10494451]     Ответить | Цитировать Сообщить модератору
 Re: Голосуем за новые фичи PG  [new]
truthwarden
Member

Откуда: Санкт Петербург
Сообщений: 1
Да, MERGE точно нужен
20 апр 11, 20:02    [10544251]     Ответить | Цитировать Сообщить модератору
 Re: Голосуем за новые фичи PG  [new]
Misha Tyurin
Member

Откуда: Тюмень
Сообщений: 2236
truthwarden,

http://wiki.postgresql.org/wiki/SQL_MERGE - заняться будет нечем, может и прикрутят
20 апр 11, 21:06    [10544392]     Ответить | Цитировать Сообщить модератору
 Re: Голосуем за новые фичи PG  [new]
Judo
Member

Откуда:
Сообщений: 690
Огласите список (здесь в топике), договоримся например что каждый может поставить по одному балу напротив каждой фичи (и у каждого например всего 3 бала в руке) и посмотрим что в итоге голосования получится....
28 апр 11, 11:50    [10579225]     Ответить | Цитировать Сообщить модератору
 Re: Голосуем за новые фичи PG  [new]
Misha Tyurin
Member

Откуда: Тюмень
Сообщений: 2236
ещё хочу иногда видеть сразу и результат запроса и его план... а то не охота по часу ждать аналайза в холостую
10 май 11, 15:45    [10630171]     Ответить | Цитировать Сообщить модератору
 Re: Голосуем за новые фичи PG  [new]
Judo
Member

Откуда:
Сообщений: 690
Misha Tyurin
ещё хочу иногда видеть сразу и результат запроса и его план... а то не охота по часу ждать аналайза в холостую


в оракле аналайз строится налету без выборки данных анализируемой таблицы и ожидания.
А вот сама выборка дело другое и может занять прилично времени. Хотя есть еще компбик: аналайз с выборкой одновременно
10 май 11, 17:20    [10630877]     Ответить | Цитировать Сообщить модератору
 Re: Голосуем за новые фичи PG  [new]
Warstone
Member

Откуда:
Сообщений: 4896
Блог
Judo
Misha Tyurin
ещё хочу иногда видеть сразу и результат запроса и его план... а то не охота по часу ждать аналайза в холостую


в оракле аналайз строится налету без выборки данных анализируемой таблицы и ожидания.
А вот сама выборка дело другое и может занять прилично времени. Хотя есть еще компбик: аналайз с выборкой одновременно
Здесь все то-же самое, кроме того, что нету комбинации и аналайз и данные. Хотя хотелось-бы. Это поможет, в некоторых случаях, узнать где надо сделать вакуум, а где и индекс построить ибо тормозим.
10 май 11, 22:17    [10632078]     Ответить | Цитировать Сообщить модератору
 Re: Голосуем за новые фичи PG  [new]
Ёш
Member

Откуда:
Сообщений: 2891
Warstone
Judo
пропущено...


в оракле аналайз строится налету без выборки данных анализируемой таблицы и ожидания.
А вот сама выборка дело другое и может занять прилично времени. Хотя есть еще компбик: аналайз с выборкой одновременно
Здесь все то-же самое, кроме того, что нету комбинации и аналайз и данные.
http://www.postgresql.org/docs/current/static/auto-explain.html
11 май 11, 11:55    [10633987]     Ответить | Цитировать Сообщить модератору
 Re: Голосуем за новые фичи PG  [new]
Misha Tyurin
Member

Откуда: Тюмень
Сообщений: 2236
Ёш
Warstone
пропущено...
Здесь все то-же самое, кроме того, что нету комбинации и аналайз и данные.
http://www.postgresql.org/docs/current/static/auto-explain.html

ага, вспомнил, видел такую штуку, спасибо.

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

вот, например, к тому же модулю как то так бы вот сделали

SET auto_explain.куда_выдавать = 'как_нотайс'
11 май 11, 12:44    [10634333]     Ответить | Цитировать Сообщить модератору
 Re: Голосуем за новые фичи PG  [new]
Ёш
Member

Откуда:
Сообщений: 2891
Misha Tyurin
Ёш
пропущено...
http://www.postgresql.org/docs/current/static/auto-explain.html

ага, вспомнил, видел такую штуку, спасибо.

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

вот, например, к тому же модулю как то так бы вот сделали

SET auto_explain.куда_выдавать = 'как_нотайс'
Что передавать в подключение клиенту — зависит от client_min_messages, можно так как-то сделать:
postgres=# load 'auto_explain';
LOAD
postgres=# set auto_explain.log_min_duration to '0ms';
SET
postgres=# set client_min_messages TO 'log';
SET
postgres=# select now();
LOG:  duration: 0.023 ms  plan:
Query Text: select now();
Result  (cost=0.00..0.01 rows=1 width=0)
              now              
-------------------------------
 2011-05-11 13:41:17.835277+04
(1 row)
ну либо можно похакать auto_explain.c, изменить
			/*
			 * Note: we rely on the existing logging of context or
			 * debug_query_string to identify just which statement is being
			 * reported.  This isn't ideal but trying to do it here would
			 * often result in duplication.
			 */
			ereport(LOG,
					(errmsg("duration: %.3f ms  plan:\n%s",
							msec, es.str->data),
					 errhidestmt(true)));

на что-то типа:
			/*
			 * Note: we rely on the existing logging of context or
			 * debug_query_string to identify just which statement is being
			 * reported.  This isn't ideal but trying to do it here would
			 * often result in duplication.
			 */
			ereport(NOTICE,
					(errmsg("duration: %.3f ms  plan:\n%s",
							msec, es.str->data),
					 errhidestmt(true)));

11 май 11, 13:49    [10635059]     Ответить | Цитировать Сообщить модератору
 Re: Голосуем за новые фичи PG  [new]
Judo
Member

Откуда:
Сообщений: 690
Misha Tyurin
Ёш
пропущено...
http://www.postgresql.org/docs/current/static/auto-explain.html

ага, вспомнил, видел такую штуку, спасибо.

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

вот, например, к тому же модулю как то так бы вот сделали

SET auto_explain.куда_выдавать = 'как_нотайс'


не знаю как в постгресе (но обязательно узнаю) но в оракле есть запись плана в лог
11 май 11, 13:58    [10635164]     Ответить | Цитировать Сообщить модератору
 Re: Голосуем за новые фичи PG  [new]
tadmin
Member

Откуда:
Сообщений: 1181
Едва ли это нужно еще кому-то, но я бы мечтал о хранении timestamp и username пользователя, который изменил ХП, view, таблицу
Если бы это еще и можно было писать в лога....
11 май 11, 15:06    [10635885]     Ответить | Цитировать Сообщить модератору
 Re: Голосуем за новые фичи PG  [new]
Judo
Member

Откуда:
Сообщений: 690
tadmin
Едва ли это нужно еще кому-то, но я бы мечтал о хранении timestamp и username пользователя, который изменил ХП, view, таблицу
Если бы это еще и можно было писать в лога....


клевая фишка, а еще бы повесить дефаулт-триггер на любую компиляцию и свою систему контроля версия заделать
11 май 11, 15:08    [10635900]     Ответить | Цитировать Сообщить модератору
 Re: Голосуем за новые фичи PG  [new]
Misha Tyurin
Member

Откуда: Тюмень
Сообщений: 2236
Ёш,

красота, точно! всё есть
11 май 11, 15:46    [10636330]     Ответить | Цитировать Сообщить модератору
 Re: Голосуем за новые фичи PG  [new]
Bond_JamesBond
Guest
1. Поддержку FULL JOIN те только через merge join
2. Custom Window Aggregate Functions в которой можно делать 2 прогона, то есть сначала пробежать рассчитать одно значение, а потом еще раз пробежать и высчитать результат с учетом этого значения (понимаю что извращение, но хотелось бы)
27 авг 11, 13:48    [11189342]     Ответить | Цитировать Сообщить модератору
 Re: Голосуем за новые фичи PG  [new]
Artemiy
Member

Откуда:
Сообщений: 1301
Недавно столкнулся с отсутствием возможности:
select count( distinct table.field ) over ( partition by ... ) from table

После Оракла это печалит весьма...
4 ноя 11, 12:33    [11550636]     Ответить | Цитировать Сообщить модератору
 Re: Голосуем за новые фичи PG  [new]
avinog
Member

Откуда:
Сообщений: 9
Поздновато я конечно сюда попал.

Мой опыт показал, что если архитектор системы идет на поводу у пользователей и пытается реализовать все их предложения, то на системе можно ставить крест :). Тем не менее выскажу идеи, реализация которых, на мой взгляд, может дать существенное конкурентное преимущество (в порядке убывания актуальности).

1. Возможность приоритезации операций ввода/вывода для различных пользователей
Скажем, есть пользователь, операции которого должны выполняться как можно быстрее. Его запросы определяют работоспособность системы в целом. Например в телефонии, это будут запросы связанные с идентификацией, авторизацией, маршрутизацией, горячим биллингом. Но запросы связанные с генерацией отчетов, выставлением счетов, должны выполняться в "фоновом" режиме.
"Дождливый" селект должен приостанавливаться, если во время его исполнения поступил более приоритетный запрос.

В Оракле есть возможность выставить приоритеты пользователям для доступа к процессору системы, но эта возможность бесполезна, поскольку узким местом, как правило, является не вычислительная мощность системы, а операции ввода/вывода. Установив, скажем пользователю квоту в 1% процессорного времени проблема решена не будет. Эта квота будет играть роль, только тогда, когда проц загружен больше 99%, а если он загружен на 30%, то при поступлении низкоприоритетного запроса, система выделит ему все свободные 70%, что совершенно правильно.

Система не должна вставать на колени, если несколько менеджеров одновременно приступили к созданию отчетов.

2. Отмена требования по удалению объектов, зависимых от модифицированного объекта
Согласитесь, было бы странно, если бы при модификации таблицы (добавление/удаление столбца, изменение типа данных) или даже при ее удалении (при пересоздании), система бы требовала удалить все хранимые процедуры и объекты, зависящие от неё.

Но это считается нормальным при работе с объектами. В результате, крайне ограниченное их использование (только при полной безысходности) в силу чрезвычайного неудобства работы с ними. Если так сделано в Оракле, то это совсем не значит, что также должно быть сделано и в PG.

3. PL/PgSQL. Реализация возможности циклического перебора элементов записи или атрибутов объекта
Что-то подобное этому:
FOR target_anyelement IN [record|object] LOOP
...
END LOOP

а еще лучше осуществить доступ к ним по "индексу".

Редко, но бывает нужно, при построении гибких систем, особенно, когда у заказчика исторически имеются таблицы с числом колонок больше сотни. Конечно, последовательный доступ к колонкам можно получить, используя имеющиеся средства, но все это настолько криво, а посему очень медленно...
6 авг 12, 10:43    [12966448]     Ответить | Цитировать Сообщить модератору
 Re: Голосуем за новые фичи PG  [new]
Maxim Boguk
Member

Откуда: Melbourne, Австралия
Сообщений: 3361
avinog
Поздновато я конечно сюда попал.

Мой опыт показал, что если архитектор системы идет на поводу у пользователей и пытается реализовать все их предложения, то на системе можно ставить крест :). Тем не менее выскажу идеи, реализация которых, на мой взгляд, может дать существенное конкурентное преимущество (в порядке убывания актуальности).

1. Возможность приоритезации операций ввода/вывода для различных пользователей
Скажем, есть пользователь, операции которого должны выполняться как можно быстрее. Его запросы определяют работоспособность системы в целом. Например в телефонии, это будут запросы связанные с идентификацией, авторизацией, маршрутизацией, горячим биллингом. Но запросы связанные с генерацией отчетов, выставлением счетов, должны выполняться в "фоновом" режиме.
"Дождливый" селект должен приостанавливаться, если во время его исполнения поступил более приоритетный запрос.

В Оракле есть возможность выставить приоритеты пользователям для доступа к процессору системы, но эта возможность бесполезна, поскольку узким местом, как правило, является не вычислительная мощность системы, а операции ввода/вывода. Установив, скажем пользователю квоту в 1% процессорного времени проблема решена не будет. Эта квота будет играть роль, только тогда, когда проц загружен больше 99%, а если он загружен на 30%, то при поступлении низкоприоритетного запроса, система выделит ему все свободные 70%, что совершенно правильно.

Система не должна вставать на колени, если несколько менеджеров одновременно приступили к созданию отчетов.

2. Отмена требования по удалению объектов, зависимых от модифицированного объекта
Согласитесь, было бы странно, если бы при модификации таблицы (добавление/удаление столбца, изменение типа данных) или даже при ее удалении (при пересоздании), система бы требовала удалить все хранимые процедуры и объекты, зависящие от неё.

Но это считается нормальным при работе с объектами. В результате, крайне ограниченное их использование (только при полной безысходности) в силу чрезвычайного неудобства работы с ними. Если так сделано в Оракле, то это совсем не значит, что также должно быть сделано и в PG.

3. PL/PgSQL. Реализация возможности циклического перебора элементов записи или атрибутов объекта
Что-то подобное этому:
FOR target_tanyelemen IN [record|object] LOOP
...
END LOOP

а еще лучше осуществить доступ к ним по "индексу".

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


1)ionice в кроне раз в минуту и разделение отчетных и приоритетных пользователей + pgbouncer чтобы коннекты жили эту проблему более менее решает. Отчеты живут с ionice -c 3 (вместе с autovacuum/pg_dump и прочими некритичными к скорости IO вещами).
Но вообще использование ssd делает эту задачу малоактуальной.

3)вероятно не будет сделано никогда так как target_tanyelement не может иметь разные типы... pl/pgsql архитектурно не умеет работать с полиморфными переменными (и не будет уметь). Так что я бы на это не расчитывал. Да и hstore workaround не такой уж ужасный на практике.
6 авг 12, 11:17    [12966680]     Ответить | Цитировать Сообщить модератору
 Re: Голосуем за новые фичи PG  [new]
avinog
Member

Откуда:
Сообщений: 9
Максим, спасибо за советы и оперативный ответ.

Maxim Boguk
1)ionice в кроне раз в минуту и разделение отчетных и приоритетных пользователей + pgbouncer чтобы коннекты жили эту проблему более менее решает. Отчеты живут с ionice -c 3 (вместе с autovacuum/pg_dump и прочими некритичными к скорости IO вещами).
Но вообще использование ssd делает эту задачу малоактуальной.
В свое время эту задачу пытались решить для Оракла путем использования ionice для задания приоритетов процессам ввода/вывода - неудачно. Для этого необходимо связать процессы ввода/вывода с пользователями, а они принадлежат одному пользователю - Oracle. Может в отношении PG я ошибаюсь. Наконец, есть еще виндовые пользователи.
И pgbouncer не поможет. Достаточно пары "красивых" селектов.

Короче, система должна быть удобной.

Maxim Boguk
3)вероятно не будет сделано никогда так как target_anyelement не может иметь разные типы... pl/pgsql архитектурно не умеет работать с полиморфными переменными (и не будет уметь). Так что я бы на это не расчитывал. Да и hstore workaround не такой уж ужасный на практике.
"вероятно не будет сделано никогда" - и не надо). С hstore я прокололся. Я их использовал на 8-ке и там функций типа hstore(record) еще не было. Спасибо, посмотрел документацию ). Помнится с ними была какая-то проблема связанная с производительностью, сейчас не вспомню, нашел какой-то workaround, чтобы они работали быстро.
6 авг 12, 16:08    [12969172]     Ответить | Цитировать Сообщить модератору
 Re: Голосуем за новые фичи PG  [new]
Maxim Boguk
Member

Откуда: Melbourne, Австралия
Сообщений: 3361
avinog
Максим, спасибо за советы и оперативный ответ.

Maxim Boguk
1)ionice в кроне раз в минуту и разделение отчетных и приоритетных пользователей + pgbouncer чтобы коннекты жили эту проблему более менее решает. Отчеты живут с ionice -c 3 (вместе с autovacuum/pg_dump и прочими некритичными к скорости IO вещами).
Но вообще использование ssd делает эту задачу малоактуальной.
В свое время эту задачу пытались решить для Оракла путем использования ionice для задания приоритетов процессам ввода/вывода - неудачно. Для этого необходимо связать процессы ввода/вывода с пользователями, а они принадлежат одному пользователю - Oracle. Может в отношении PG я ошибаюсь. Наконец, есть еще виндовые пользователи.
И pgbouncer не поможет. Достаточно пары "красивых" селектов.

Короче, система должна быть удобной.


crontab -l
...

* * * * * ps -u postgres x | grep -E 'autovacuum|COPY|pg_dump|cron_role|report_role' | grep -v grep | perl -pe 's/^\s*(\d+) .*$/$1/' | xargs --no-run-if-empty -I $ ionice -c 3 -t -p $

куда уж проще то...

+ pgbouncer чтобы коннекты от cron_role и report_role жили более менее перманетно с выставленным ionice уже...
пользуюсь тем что в ps -u postgres x есть имя пользователя подключенного к базе

29841 ? Ss 0:07 postgres: cron_role somedb [local] idle
30072 ? Ss 0:04 postgres: report_role somedb [local] idle
...

Таким образом в 99% случаев любой запрос от cron_role или report_role уже идет с низким IO priority


PS: windows + Pg в production использовать НЕ НАДО.
6 авг 12, 16:17    [12969253]     Ответить | Цитировать Сообщить модератору
 Re: Голосуем за новые фичи PG  [new]
Warstone
Member

Откуда:
Сообщений: 4896
Блог
Maxim Boguk
crontab -l
...

* * * * * ps -u postgres x | grep -E 'autovacuum|COPY|pg_dump|cron_role|report_role' | grep -v grep | perl -pe 's/^\s*(\d+) .*$/$1/' | xargs --no-run-if-empty -I $ ionice -c 3 -t -p $

куда уж проще то...
Я что, опять отмонтировать забыла?!!
(С) Анекдот.
6 авг 12, 19:36    [12970787]     Ответить | Цитировать Сообщить модератору
 Re: Голосуем за новые фичи PG  [new]
Ёш
Member

Откуда:
Сообщений: 2891
perl -pe 's/^\s*(\d+) .*$/$1/'
можно на
awk '{print $1}'
поменять наверное
6 авг 12, 19:52    [12970862]     Ответить | Цитировать Сообщить модератору
 Re: Голосуем за новые фичи PG  [new]
ОКТОГЕН
Member

Откуда:
Сообщений: 2479
Обещают матвью в 9.3 кажись
12 апр 13, 14:14    [14172863]     Ответить | Цитировать Сообщить модератору
 Re: Голосуем за новые фичи PG  [new]
ОКТОГЕН
Member

Откуда:
Сообщений: 2479
Кто-нибудь начал использовать EXTENSION'сы в разработке?
Можно ли стало запросом получить дерево зависимостей расширений,
или лазать по манифестам надо?
12 апр 13, 14:17    [14172885]     Ответить | Цитировать Сообщить модератору
 Re: Голосуем за новые фичи PG  [new]
Ёш
Member

Откуда:
Сообщений: 2891
ОКТОГЕН, ну зависимости там какие-то есть, не знаю правда какие :)

select * from pg_depend where 'pg_extension'::regclass in (classid, refclassid);
12 апр 13, 16:50    [14174258]     Ответить | Цитировать Сообщить модератору
 Re: Голосуем за новые фичи PG  [new]
DRVTiny
Member

Откуда:
Сообщений: 40
Логи изменений в базе в виде SQL-запросов, которые можно было бы применить к базовому бэкапу в SQL-формате и получить результирующую базу на момент времени N.
29 апр 13, 16:16    [14245086]     Ответить | Цитировать Сообщить модератору
 Re: Голосуем за новые фичи PG  [new]
DarkHobbit
Member

Откуда:
Сообщений: 13
Maxim Boguk
windows + Pg в production использовать НЕ НАДО.

Кстати, а можно обосновать, почему?
30 авг 13, 09:23    [14774163]     Ответить | Цитировать Сообщить модератору
 Re: Голосуем за новые фичи PG  [new]
Maxim Boguk
Member

Откуда: Melbourne, Австралия
Сообщений: 3361
DarkHobbit
Maxim Boguk
windows + Pg в production использовать НЕ НАДО.

Кстати, а можно обосновать, почему?


Win не нативная для базы платформа... это как Mssql пытаться на Linux отпортировать...
В итоге постоянная куча проблем которые на unix платформах не наблюдаются в принципе
(да их можно обойти в теории... но всеравно проблемы).

Классическая ситуация до появления pg_terminate_backend - как на винде снять рабочий коннект к базе...
на unix просто - kill -TERM pid
А на Win упс без плясок с бубном... снятие через process manager - эквивалент kill -KILL pid и вызывает рестарт базы...
Проблемы с правами на директории... проблемы с логами и ротацией...
Проблемы с выделением памяти... в общем много всего...
Под низкой нагрузкой это все работает... а когда надо максимум из железа выжать - начинаются грабли.

PS: это не значит что принципиально нельзя использовать Pg под Win... просто стоит ожидать сильно больше неожиданных проблем на ровном месте по мере роста нагрузки.
30 авг 13, 09:31    [14774190]     Ответить | Цитировать Сообщить модератору
 Re: Голосуем за новые фичи PG  [new]
andrei-k23
Member

Откуда:
Сообщений: 4
Сделать динамический курсор как в MS Access!
Чтобы можно было один раз выполнить общий запрос, а потом курсором в нем искать все что нужно. А не как сейчас можно только перемещать курсор максимум на заданное число строк...
7 май 14, 18:56    [15987358]     Ответить | Цитировать Сообщить модератору
 Re: Голосуем за новые фичи PG  [new]
Ivan Durak
Member

Откуда: Minsk!!!
Сообщений: 3268
andrei-k23
Сделать динамический курсор как в MS Access!
Чтобы можно было один раз выполнить общий запрос, а потом курсором в нем искать все что нужно. А не как сейчас можно только перемещать курсор максимум на заданное число строк...

для чего? поясните на примере
13 июн 14, 10:12    [16160676]     Ответить | Цитировать Сообщить модератору
 Re: Голосуем за новые фичи PG  [new]
PCContra
Member

Откуда: Торжок, Тверская область, Россия
Сообщений: 297
Кто поддержит такую "фичу":
array foreign key - чтобы была возможность добавит внешний ключ к массиву
?

CREATE TABLE a(
   id INT PRIMARY KEY
);

CREATE TABLE b(
   x INT PRIMARY KEY, 
   ids INT[] REFERENCES a
);

?
9 июл 14, 15:50    [16281900]     Ответить | Цитировать Сообщить модератору
 Re: Голосуем за новые фичи PG  [new]
Ivan Durak
Member

Откуда: Minsk!!!
Сообщений: 3268
Bond_JamesBond
1. Поддержку FULL JOIN те только через merge join
2. Custom Window Aggregate Functions в которой можно делать 2 прогона, то есть сначала пробежать рассчитать одно значение, а потом еще раз пробежать и высчитать результат с учетом этого значения (понимаю что извращение, но хотелось бы)

1. Must have
2. Этож просто обернуть подзапросом первую можно, не?
9 июл 14, 16:03    [16281989]     Ответить | Цитировать Сообщить модератору
 Re: Голосуем за новые фичи PG  [new]
Izya
Member

Откуда:
Сообщений: 188
Когда-то обещали при наследовании таблиц индексы сделать так, что бы они и на подтаблицы распространялись. Наследование таблиц бывает нужным, но без индексов - это гарантированные тормоза (как часто бывает - идея хорошая, но из-за кривой реализации ею никто не пользуется). Есть движение в этом направлении?
3 сен 14, 16:06    [16530218]     Ответить | Цитировать Сообщить модератору
 Re: Голосуем за новые фичи PG  [new]
hattifattener
Member

Откуда: Киев
Сообщений: 16
Рискну предложить рекурсивную операцию смены пользователя для групп сущностей.
Вроде
CHOWN [user] [database|schema|table|...] [name]
13 янв 15, 18:19    [17112610]     Ответить | Цитировать Сообщить модератору
 Re: Голосуем за новые фичи PG  [new]
ОКТОГЕН
Member

Откуда:
Сообщений: 2479
Валидация функций и расширений
Очень поможет избегать ошибок в критичных приложениях.
У каждой функции при коммите будет проверяться статус, если она validate, то проверяются объекты на существование, validate,
статус valid,отсутствие DDL и динамического SQL, если сохраняемая функция invalid, то рекурсивно по зависимостям делаются
такими же все расширения и функции, которые зависят от оной.
Эта фича зависит от global temporary tables как в oracle.
Голосуйте.
4 июл 15, 15:05    [17852062]     Ответить | Цитировать Сообщить модератору
 Re: Голосуем за новые фичи PG  [new]
qwwq
Member

Откуда:
Сообщений: 2277
ОКТОГЕН
Валидация функций и расширений
Очень поможет избегать ошибок в критичных приложениях.
У каждой функции при коммите будет проверяться статус, если она validate, то проверяются объекты на существование, validate,
статус valid,отсутствие DDL и динамического SQL, если сохраняемая функция invalid, то рекурсивно по зависимостям делаются
такими же все расширения и функции, которые зависят от оной.
Эта фича зависит от global temporary tables как в oracle.
Голосуйте.
а как бы вас там заминусовать ?
ара--калоеды, такие калоеды, ара
4 июл 15, 15:16    [17852082]     Ответить | Цитировать Сообщить модератору
 Re: Голосуем за новые фичи PG  [new]
ОКТОГЕН
Member

Откуда:
Сообщений: 2479
qwwq
а как бы вас там заминусовать ?
ара--калоеды, такие калоеды, ара

По-хорошему, минусят именно за такие посты, ну да пофиг.
Не вопрос - там есть такая кнопочка <delete>.
Вы, батенька, убедительно доказываете, почему предложение плохое
и чем будет реализация мешать остальным. Докажете - выпилю.
4 июл 15, 19:00    [17852455]     Ответить | Цитировать Сообщить модератору
 Re: Голосуем за новые фичи PG  [new]
qwwq
Member

Откуда:
Сообщений: 2277
ОКТОГЕН
qwwq
а как бы вас там заминусовать ?
ара--калоеды, такие калоеды, ара

По-хорошему, минусят именно за такие посты, ну да пофиг.
Не вопрос - там есть такая кнопочка <delete>.
Вы, батенька, убедительно доказываете, почему предложение плохое
и чем будет реализация мешать остальным. Докажете - выпилю.



предложение никакое
до тех пор, пока его не внедрят в лучших традициях -- "как всегда"

а вот если "инвалид" не даст мне запустить эту функцию -- то оно ещё и вредное.
например в ф--ии что-то типа
IF FALSE THEN
   SELECT my_invalid_fun(...)
ELSE
где вместо false -- не выполняющиеся при сегодняшних данных условия
-- я нормально оставлю эту функцию работать, починю другую, и всё будет удобно и без необходимости дёргаться, только из-за того, что какие-то ушлёпки продавили лишнюю функциональность

но если по-человечески будет просто информировать -- то да и хрен с ним.

к тому же вы наверное конкретный pl имеете в виду ? или вы на всех языках собираетесь отслеживать валидность ?


а вот то, что при удалении наследника из иерархии [NO INHERIT] или при его дропе -- в конкурирующих транзакциях вылетает ошибка [как было в 7-ке после дропа индекса], и , кому надо, знают об этом N лет, и там конь не то, что не валялся, но и не собирается валяться -- вот это херово. И такого "херово" можно ещё понасобирать.
4 июл 15, 19:58    [17852569]     Ответить | Цитировать Сообщить модератору
 Re: Голосуем за новые фичи PG  [new]
ОКТОГЕН
Member

Откуда:
Сообщений: 2479
qwwq, если б вы были внимательнее, то наверняка б увидели, что на этот случай,
если вы не хотите пользоваться валидацией, при создании функции говорите
CREATE FUNCTION namefunc(...)
$$
DECLARE
...
BEGIN
...
END
$$
...
NOT VALIDATE;

По умолчанию такое поведение можно запилить.
И функция ведёт себя так же, как сейчас.
И даже старый код так же себя будет вести.
Хотите работать в прежнем режиме - не устанавливайте validate.
Думаю, не на всех процедурных языках этот механизм можно сделать,
подозреваю, только на жёстко типизированных, как pl\pgsql
Как вариант - на тех, что нельзя - принудительно задавать флаг валидности функции true,
чтоб не рушилось ничего, а эту опцию при создании функции делать validate.
ЗЫ
В оракле, насколько мне известно, с конкурирующими созданиями функций вообще всё плохо.
4 июл 15, 20:49    [17852672]     Ответить | Цитировать Сообщить модератору
 Re: Голосуем за новые фичи PG  [new]
bochkov
Member

Откуда: Камчатка
Сообщений: 4032
хочу INSERT ON DUPLICATE UPDATE
5 июл 15, 01:03    [17853250]     Ответить | Цитировать Сообщить модератору
 Re: Голосуем за новые фичи PG  [new]
ОКТОГЕН
Member

Откуда:
Сообщений: 2479
bochkov
хочу INSERT ON DUPLICATE UPDATE

дык, в 9.5 уже будет.
Что толку хотеть?
Хотеть надо чего-то другого, например того, что я тут насочинял.
Или двоичный бэкап инкрементальный, совместимый обратно начиная с какой-то определённой версии и выше.
БэДээРки.
Вотки тоже можно хотеть)))
5 июл 15, 02:32    [17853347]     Ответить | Цитировать Сообщить модератору
 Re: Голосуем за новые фичи PG  [new]
bochkov
Member

Откуда: Камчатка
Сообщений: 4032
еще хочу возможность по запросу получать предыдущую или следующую запись
согласно сортировки выбранного индекса
5 июл 15, 03:46    [17853371]     Ответить | Цитировать Сообщить модератору
 Re: Голосуем за новые фичи PG  [new]
Alexius
Member

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

полезно для защиты от засорения логов особо одаренными личностями, передающими миллион id в выражении IN, например. или bulk insert запросами вместо copy. или километровыми запросами с case выражениями. или еще чем, тут фантазия безгранична.

стоит ли куда-то писать или уже обсуждалось? сделать наверное не сложно.
5 июл 15, 10:54    [17853503]     Ответить | Цитировать Сообщить модератору
 Re: Голосуем за новые фичи PG  [new]
qwwq
Member

Откуда:
Сообщений: 2277
ОКТОГЕН
qwwq, если б вы были внимательнее, то наверняка б увидели,

а я и видел, но опасаюсь зазора меж задумкой и реализацией ("как лучше" vs "как всегда")

и да, немного вспылил, "вёл себя недостойно звания савецкага афицера"

ОКТОГЕН
В оракле, насколько мне известно, с конкурирующими созданиями функций вообще всё плохо.
это, насколько я понимаю, разница между интерпретацией и компиляцией. т.е. строгая валидация [при компиляции] в оракле -- неизбежность, а не фича.

могу врать, ессно. [ имхо, составленное с чужих слов и из общих соображений ]
5 июл 15, 14:02    [17853801]     Ответить | Цитировать Сообщить модератору
 Re: Голосуем за новые фичи PG  [new]
ОКТОГЕН
Member

Откуда:
Сообщений: 2479
qwwq, в PG делают лучше всё))) Как-то всё ладно скроено, по стандартам и предсказуемо.
Работа с последовательностями в PG намного удобнее сделана, нежели в красном конкуренте.
Там никаких SERIAL, никаких DEFAULT nextval('nameseq') в столбцах. Всё на триггерах, ручками.
Пустая строка к NULL не приравнивается, а как в стандарте.
WITH опять же, как надо, да ещё и returning можно выводить.
Это то что вспомнил, наверняка если покопаться - можно найти ещё каких-нибудь корок или залипух.
Подозреваю, что INSERT ... ON CONFLICT в 9.5 тоже лучше сделали.
5 июл 15, 15:55    [17854006]     Ответить | Цитировать Сообщить модератору
 Re: Голосуем за новые фичи PG  [new]
Ivan Durak
Member

Откуда: Minsk!!!
Сообщений: 3268
автор
Как-то всё ладно скроено, по стандартам и предсказуемо.

вот это и надо поддерживать.
6 июл 15, 10:16    [17856022]     Ответить | Цитировать Сообщить модератору
 Re: Голосуем за новые фичи PG  [new]
akhan
Member

Откуда:
Сообщений: 69
JOB-ы
14 авг 15, 09:15    [18016298]     Ответить | Цитировать Сообщить модератору
 Re: Голосуем за новые фичи PG  [new]
roadster
Member [заблокирован]

Откуда: "Церковь тяжеловооружённого Христа" ©
Сообщений: 52505
боюсь спросить, а аналог ораклового model есть в pg?
14 авг 15, 16:54    [18019148]     Ответить | Цитировать Сообщить модератору
 Re: Голосуем за новые фичи PG  [new]
Maxim Boguk
Member

Откуда: Melbourne, Австралия
Сообщений: 3361
roadster
боюсь спросить, а аналог ораклового model есть в pg?


А вы расскажите что это такое за зверь. Тут далеко не все в Oracle спецы.

--
Maxim Boguk
www.postgresql-consulting.ru
14 авг 15, 17:52    [18019496]     Ответить | Цитировать Сообщить модератору
 Re: Голосуем за новые фичи PG  [new]
roadster
Member [заблокирован]

Откуда: "Церковь тяжеловооружённого Христа" ©
Сообщений: 52505
Maxim Boguk
Тут далеко не все в Oracle спецы.

я думал здесь есть те, кто мигрировал с оракла.
Maxim Boguk
А вы расскажите что это такое за зверь.

вот здесь написано подробно http://docs.oracle.com/cd/B19306_01/server.102/b14223/sqlmodel.htm
ну и пример от туда же
SELECT SUBSTR(country, 1, 20) country, 
      SUBSTR(product, 1, 15) product, year, sales
FROM sales_view
WHERE country IN ('Italy', 'Japan')
MODEL
  PARTITION BY (country) DIMENSION BY (product, year)
  MEASURES (sales sales)
  RULES 
  (sales['Bounce', 2002] = sales['Bounce', 2001] + sales['Bounce', 2000],
   sales['Y Box', 2002] = sales['Y Box', 2001],
   sales['All_Products', 2002] = sales['Bounce', 2002] + sales['Y Box', 2002])
ORDER BY country, product, year;

смысл в следующем - задаём партицию, определяем измерения и правила расчёта измерений, для которых данные не хранятся.
20 авг 15, 09:59    [18044000]     Ответить | Цитировать Сообщить модератору
 Re: Голосуем за новые фичи PG  [new]
roadster
Member [заблокирован]

Откуда: "Церковь тяжеловооружённого Христа" ©
Сообщений: 52505
и всё это в едином запросе.
20 авг 15, 10:00    [18044006]     Ответить | Цитировать Сообщить модератору
 Re: Голосуем за новые фичи PG  [new]
p2.
Member

Откуда:
Сообщений: 523
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]     Ответить | Цитировать Сообщить модератору
 Re: Голосуем за новые фичи PG  [new]
Legushka
Member

Откуда: Казань
Сообщений: 609
не хватает условий в оконных функциях.
18 дек 15, 15:53    [18579046]     Ответить | Цитировать Сообщить модератору
 Re: Голосуем за новые фичи PG  [new]
Ivan Durak
Member

Откуда: Minsk!!!
Сообщений: 3268
Legushka
не хватает условий в оконных функциях.

например?
18 дек 15, 15:54    [18579064]     Ответить | Цитировать Сообщить модератору
 Re: Голосуем за новые фичи PG  [new]
Lonepsycho
Member

Откуда: Siauliai, Литва
Сообщений: 484
чего мне нехватает, так планера который бы учитывал FOREIGN KEY как CONSTRAINT при создании планов для запросов. например для запросов которые идут на таблицы с наследниками.
18 дек 15, 16:51    [18579478]     Ответить | Цитировать Сообщить модератору
 Re: Голосуем за новые фичи PG  [new]
qwwq
Member

Откуда:
Сообщений: 2277
читаю http://habrahabr.ru/post/274659/
BRIN-индексы


когда--то пытался понять, ускорит ли такое индексирование поля xmin [напр -- по условию where xmin <>2] вакуумирование "to prevent wrapparrond" больших баз, большая часть которых архивна, а в меньшей идёт активная жизнь. навскидку казалось, что должно. и существенно. (сейчас оно периодически молотит старые таблицы неделями).

нет ?
12 янв 16, 17:07    [18668265]     Ответить | Цитировать Сообщить модератору
 Re: Голосуем за новые фичи PG  [new]
Павел Лузанов
Member

Откуда:
Сообщений: 402
qwwq,

Хитро заходишь. Узнаешь ответ - поделись.
13 янв 16, 14:08    [18672705]     Ответить | Цитировать Сообщить модератору
 Re: Голосуем за новые фичи PG  [new]
qwwq
Member

Откуда:
Сообщений: 2277
Павел Лузанов,

кто из нас двоих работает в геркулесе постгрес--проффешенле?

я от вас хотел узнать, не приделали ли подобную БРИНУ штуковину к прокрутке frize-уемых объектов на предмет необходимости выставления в 2-ку. Чтобы значит целые блоки можно было не читать.
кажется что именно отсюда должна была родиться идея БРИН, а не наоборот.

уж очень оно на больших активно пишущих (в малую часть) базах накладно -- всё растущую базу на предмет фриза всё время прокручивать.
13 янв 16, 14:31    [18672854]     Ответить | Цитировать Сообщить модератору
 Re: Голосуем за новые фичи PG  [new]
Павел Лузанов
Member

Откуда:
Сообщений: 402
qwwq
не приделали ли подобную БРИНУ штуковину к прокрутке frize-уемых объектов

Не сомневаюсь, что не приделали.
А вот может ли помочь - это надо посмотреть.
13 янв 16, 18:22    [18674416]     Ответить | Цитировать Сообщить модератору
 Re: Голосуем за новые фичи PG  [new]
PCContra
Member

Откуда: Торжок, Тверская область, Россия
Сообщений: 297
Postgres пока (версия 9.5) не умеет сравнивать тип данных JSON друг с другом
ЖДУ.
28 янв 16, 13:10    [18739903]     Ответить | Цитировать Сообщить модератору
 Re: Голосуем за новые фичи PG  [new]
Maxim Boguk
Member

Откуда: Melbourne, Австралия
Сообщений: 3361
qwwq
Павел Лузанов,

кто из нас двоих работает в геркулесе постгрес--проффешенле?

я от вас хотел узнать, не приделали ли подобную БРИНУ штуковину к прокрутке frize-уемых объектов на предмет необходимости выставления в 2-ку. Чтобы значит целые блоки можно было не читать.
кажется что именно отсюда должна была родиться идея БРИН, а не наоборот.

уж очень оно на больших активно пишущих (в малую часть) базах накладно -- всё растущую базу на предмет фриза всё время прокручивать.


В эту сторону смотрят активно:
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]     Ответить | Цитировать Сообщить модератору
 Re: Голосуем за новые фичи PG  [new]
Maxim Boguk
Member

Откуда: Melbourne, Австралия
Сообщений: 3361
PCContra
Postgres пока (версия 9.5) не умеет сравнивать тип данных JSON друг с другом
ЖДУ.


Если вам по строго равенству то ::text = ::text вас вполне спасет.
Или вы что то другое имеете в виду?
28 янв 16, 13:56    [18740242]     Ответить | Цитировать Сообщить модератору
 Re: Голосуем за новые фичи PG  [new]
qwwq
Member

Откуда:
Сообщений: 2277
Maxim Boguk
PCContra
Postgres пока (версия 9.5) не умеет сравнивать тип данных JSON друг с другом
ЖДУ.


Если вам по строго равенству то ::text = ::text вас вполне спасет.
Или вы что то другое имеете в виду?

а вот hstore хотя бы всегда упорядочивает пары по ключам. т.е. там это был бы правильный финт ушами. А в жейсоне в 9.4 не похоже чтобы в узлах хотя бы по ключам упорядочивало. м.б. в jsonb оно как--то лучшее чуть ?

короче -- тьху на него три раза. и популейтит он через раз. и сравнения на нём кривые. и вообще.
28 янв 16, 14:44    [18740606]     Ответить | Цитировать Сообщить модератору
 Re: Голосуем за новые фичи PG  [new]
Misha Tyurin
Member

Откуда: Тюмень
Сообщений: 2236
автор
вероятно что в 9.5 это войдет


Максим, в 95 точно не вошло уже. может в 97...
29 янв 16, 15:14    [18745976]     Ответить | Цитировать Сообщить модератору
 Re: Голосуем за новые фичи PG  [new]
ОКТОГЕН
Member

Откуда:
Сообщений: 2479
В pg есть двоичный формат резервной копии.
Реально не хватает возможности просмотра дампа вовнутрь
1)Просмотра списка объектов и их структуры
2)Возможности просмотра данных таблиц, и/или экспорта этих данных в
CSV/SQL
9 фев 16, 10:27    [18791465]     Ответить | Цитировать Сообщить модератору
 Re: Голосуем за новые фичи PG  [new]
Maxim Boguk
Member

Откуда: Melbourne, Австралия
Сообщений: 3361
ОКТОГЕН
В pg есть двоичный формат резервной копии.
Реально не хватает возможности просмотра дампа вовнутрь
1)Просмотра списка объектов и их структуры
2)Возможности просмотра данных таблиц, и/или экспорта этих данных в
CSV/SQL


Вы о:

pg_restore -F c --list my.dymp
pg_restore -F c -s --file=dbshema.sql my.dymp
pg_restore -F c --table=mytable --file=mytable.sql my.dump
?
9 фев 16, 10:35    [18791496]     Ответить | Цитировать Сообщить модератору
 Re: Голосуем за новые фичи PG  [new]
Павел Лузанов
Member

Откуда:
Сообщений: 402
Павел Лузанов
qwwq
не приделали ли подобную БРИНУ штуковину к прокрутке frize-уемых объектов

Не сомневаюсь, что не приделали.

Приделали карту заморозки страниц, в которую смотрит vacuum. В 9.6 будет.
11 мар 16, 10:32    [18918693]     Ответить | Цитировать Сообщить модератору
 Re: Голосуем за новые фичи PG  [new]
qwwq
Member

Откуда:
Сообщений: 2277
а чо, уважаемые, будут ли нормальные "родные" автономии в plpgsql , чтобы ,значит, в дереве локов всё, и дедлоки снимались?

+
что--то мой склероз меня подводит. вроде как обещаны. а полез искать -- по autonomous -- нихт.
у авторов полнотекста на "пж.про" так ващще поиск по сайту не найден (наверное плохо искал) -- буэ
31 мар 16, 17:01    [19001320]     Ответить | Цитировать Сообщить модератору
 Re: Голосуем за новые фичи PG  [new]
Серджио
Member

Откуда:
Сообщений: 12
Было бы неплохо использовать подзапросы в CHECK
14 май 16, 18:21    [19173273]     Ответить | Цитировать Сообщить модератору
 Re: Голосуем за новые фичи PG  [new]
Локшин Марк
Member

Откуда: Воронеж
Сообщений: 3042
Серджио,

Триггер напиши, и будет нужный функционал. Вообще в каких-то СУБД в CHECK можно писать подзапрос?
14 май 16, 19:28    [19173371]     Ответить | Цитировать Сообщить модератору
 Re: Голосуем за новые фичи PG  [new]
p2.
Member

Откуда:
Сообщений: 523
Серджио
Было бы неплохо использовать подзапросы в CHECK
нет смысла в декларативности ограничения, которое зависит от стечения закомиченности данных на какой-то момент.
14 май 16, 22:04    [19173819]     Ответить | Цитировать Сообщить модератору
 Re: Голосуем за новые фичи PG  [new]
qwwq
Member

Откуда:
Сообщений: 2277
Павел Лузанов
Павел Лузанов
пропущено...

Не сомневаюсь, что не приделали.

Приделали карту заморозки страниц, в которую смотрит vacuum. В 9.6 будет.

"возвращаясь к напечатанному"

появилась статейка ПгП.
https://habrahabr.ru/company/postgrespro/blog/301238/

++:
1 полезна как пальцевая для админов, борющихся с фризом
2. кажется будет ещё одна припарка незначительная (см в тексте про тхид самого факьюма) -- думаю -- пустое. но и статья пустовата

--:
1. не затронута разница read only и пишущих
2. выпал из внимания момент, когда именно транза получает тхид (становится пишущей)
3. ничего не сказано о номерах "сабтранзакций" (рост xmin за сейвпойнтами == в блоках исключений) -- т.е. выпадает из понимания полезность новых фичь, позволяющих делать то же, что раньше, но без блоков обработки (того же мерджа). -- а это уже важно для кодеров --если у вас данное приходит пачками по 1000/транзакцию, и каждое -- обрабатывается в хранимке (or триггере) в блоке исключения -- у вас счётчик вырастет на 1000. если же вам удастся вытеснить блок на задворки -- только для редких случаев -- счетчик, за весь пакет, возрастет всего на законную единичку -- сейвпойнтов--то нет.

ну и т.п.


но для админов, в качестве пальцевой иллюстрации самого механизма -- очень пользительно, я щетаю. т.ч. рекомендую.
20 май 16, 12:55    [19197872]     Ответить | Цитировать Сообщить модератору
 Re: Голосуем за новые фичи PG  [new]
Павел Лузанов
Member

Откуда:
Сообщений: 402
qwwq
1. не затронута разница read only и пишущих
2. выпал из внимания момент, когда именно транза получает тхид (становится пишущей)
3. ничего не сказано о номерах "сабтранзакций" (рост xmin за сейвпойнтами == в блоках исключений) -- т.е. выпадает из понимания полезность новых фичь, позволяющих делать то же, что раньше, но без блоков обработки (того же мерджа). -- а это уже важно для кодеров --если у вас данное приходит пачками по 1000/транзакцию, и каждое -- обрабатывается в хранимке (or триггере) в блоке исключения -- у вас счётчик вырастет на 1000. если же вам удастся вытеснить блок на задворки -- только для редких случаев -- счетчик, за весь пакет, возрастет всего на законную единичку -- сейвпойнтов--то нет.

Про это есть в теме 3 "Страницы и версии строк":
http://www.postgrespro.ru/education/courses/DBA2

Там можно презентацию и видео найти.
Конструктивная критика будет очень полезна.
20 май 16, 20:00    [19200367]     Ответить | Цитировать Сообщить модератору
 Re: Голосуем за новые фичи PG  [new]
Насяльника
Member

Откуда:
Сообщений: 436
CLUSTER
14 окт 16, 13:58    [19781705]     Ответить | Цитировать Сообщить модератору
 Re: Голосуем за новые фичи PG  [new]
vyegorov
Member

Откуда: Рига
Сообщений: 970
Lonepsycho
чего мне нехватает, так планера который бы учитывал FOREIGN KEY как CONSTRAINT при создании планов для запросов. например для запросов которые идут на таблицы с наследниками.

Это? (Третий пункт в списке.)
27 окт 16, 23:24    [19831147]     Ответить | Цитировать Сообщить модератору
 Re: Голосуем за новые фичи PG  [new]
Lonepsycho
Member

Откуда: Siauliai, Литва
Сообщений: 484
vyegorov
Lonepsycho
чего мне нехватает, так планера который бы учитывал FOREIGN KEY как CONSTRAINT при создании планов для запросов. например для запросов которые идут на таблицы с наследниками.

Это? (Третий пункт в списке.)


похоже, что на это намекают. будем тестировать, посмотрим. интересно какой план будет построен.
28 окт 16, 12:14    [19832823]     Ответить | Цитировать Сообщить модератору
 Re: Голосуем за новые фичи PG  [new]
MMM_Corp
Member

Откуда: Тернопіль, Україна
Сообщений: 2096
очень хочу профайлер как в mssql, жуть как не хватает..... эм... а может уже такой есть?
25 ноя 16, 02:06    [19932317]     Ответить | Цитировать Сообщить модератору
 Re: Голосуем за новые фичи PG  [new]
ЖEHbKA
Member [заблокирован]

Откуда:
Сообщений: 150
MMM_Corp
очень хочу профайлер как в mssql, жуть как не хватает..... эм... а может уже такой есть?


log_min_duration_statement = 0


Показывает сразу BIND - это очень удобно.

Жаль что все пишет, фильтр делать нельзя.
10 май 17, 12:05    [20468508]     Ответить | Цитировать Сообщить модератору
 Re: Голосуем за новые фичи PG  [new]
ЖEHbKA
Member [заблокирован]

Откуда:
Сообщений: 150
А я хочу чтобы постгрес мог сам запускать в себе задания по расписанию, без зависимости от ОС.

Где за такое проголосовать?
10 май 17, 12:06    [20468516]     Ответить | Цитировать Сообщить модератору
 Re: Голосуем за новые фичи PG  [new]
Alex__kK
Member

Откуда:
Сообщений: 201
1. Хочу автономки как в оракле
2. Хочу шедулер поддерживаемый бд а не отдельностоящий костыль
3. Хочу чтобы в pg_dump, когда экспортируешь только данные из таблички, можно было бы задавать условие (аналог QUERY в expdp в оракле)
28 июн 17, 15:28    [20597083]     Ответить | Цитировать Сообщить модератору
 Re: Голосуем за новые фичи PG  [new]
bochkov
Member

Откуда: Камчатка
Сообщений: 4032
insert .. on conflict работает
только с одним ограничением
хочу чтобы все конфликты умел перехватывать
28 июн 17, 15:36    [20597119]     Ответить | Цитировать Сообщить модератору
 Re: Голосуем за новые фичи PG  [new]
qwwq
Member

Откуда:
Сообщений: 2277
не нашол в предложениях
index organized table

неужто никому не надо ?

хотя лучше что--то типа:
create index on /*!not materialized!*/ VIEW


-- типа излишнюю нормализацию бороть без излишне тяжолых рукопашных структур. /* лично мне это интересно на подвернувшемся EAV-е посмотреть */

//за неимением сошол бы и ИОТ -- я бы триггерами сам обвесился .
------
зы.
+
имею аберрацию памяти, что где--то тут давно видел прямой селект из индекса , и даже пробовал якобы сам -- и получалось. но найти не удаётся. а пж честно отвечает: 42809.
13 авг 17, 19:13    [20720140]     Ответить | Цитировать Сообщить модератору
 Re: Голосуем за новые фичи PG  [new]
PgSQLanonymous3
Member

Откуда:
Сообщений: 41
qwwq
не нашол в предложениях
index organized table
неужто никому не надо ?
https://www.postgresql.org/message-id/9362e74e1002211111n533646c8q8b5c074568267f04@mail.gmail.com
14 авг 17, 09:47    [20720916]     Ответить | Цитировать Сообщить модератору
 Re: Голосуем за новые фичи PG  [new]
qwwq
Member

Откуда:
Сообщений: 2277
PgSQLanonymous3
qwwq
не нашол в предложениях
index organized table
неужто никому не надо ?
https://www.postgresql.org/message-id/9362e74e1002211111n533646c8q8b5c074568267f04@mail.gmail.com

вот я про это:
https://www.postgresql.org/message-id/407d949e1002220229w1e781755jd1754dbf94201ba7@mail.gmail.com
> > a) IOT has both table and index in one structure. So no duplication of data

-- мне для рукопашной реализации "index on join" в EAV , поскольку горничной нет. и лишняя куча данных мне в корень не упёрлась. я бы даже на отложенный сбор мусора согласился, ага. т.е. видеть лишнее старое.

вообще говоря где--то "индексы на join--ы" (назовём их "jindex") реализованы ? так чтобы несколько указателей на несколько записей одной или нескольких таблиц. и чтобы планировщик умел их иметь в виду ?

тосты ведь как--то [в индекс//по индексу] подтягиваются, тут примерно та же техника потребуется. нет ?
14 авг 17, 11:40    [20721295]     Ответить | Цитировать Сообщить модератору
 Re: Голосуем за новые фичи PG  [new]
qwwq
Member

Откуда:
Сообщений: 2277
PgSQLanonymous3,

"не нашёл" имелось ввиду здесь:
web_fox
Голосовать здесь

или предлагаем свои



типа как тут
https://postgresql.uservoice.com/forums/21853-general/suggestions/1378161-insert-nowait-update-nowait
14 авг 17, 11:50    [20721318]     Ответить | Цитировать Сообщить модератору
 Re: Голосуем за новые фичи PG  [new]
bochkov
Member

Откуда: Камчатка
Сообщений: 4032
до сих пор жду
нормальный, поддерживающий
множественные ограничения
insert ... on conflict ...
14 авг 17, 12:48    [20721551]     Ответить | Цитировать Сообщить модератору
 Re: Голосуем за новые фичи PG  [new]
p2.
Member

Откуда:
Сообщений: 523
bochkov
до сих пор жду
Он опять поспал немножко
И опять взглянул в окошко,
Увидал большой вокзал,
Потянулся и сказал:
...
15 авг 17, 01:42    [20723712]     Ответить | Цитировать Сообщить модератору
 Re: Голосуем за новые фичи PG  [new]
qwwq
Member

Откуда:
Сообщений: 2277
p2.,
автор
Он опъядь поспал немножъко


пока вспомнилось:
кроме нового варианта array_agg (зачем--то проверяющего длины, при полном бардаке в массивах пж. но пусть будет, раз сделали)
нужен array_agg(anyarray) AS append
т.е. сплошь и рядом вот такое пока даром не надо

SELECT array_agg(x) FROM 
	(SELECT ARRAY_AGG(G) x
		FROM generate_series(1, 1000) i
		--,lateral generate_series(0,(random()*i)::int +1) g 
-- какого хера они тут припустились проверять длины,
-- когда в пж-- массивы можно хоть лягушку засовывать
		,lateral generate_series(0 + i%17,100+ i%17) g 
	group by i
	) foo;


а надо что-то, реализующее примерно такое, но одним словом:

SELECT array_agg(y order by i,ord) FROM --array_agg_append
	(SELECT ARRAY_AGG(G) x,i
		FROM generate_series(1, 1000) i
		,lateral generate_series(0,(random()*i)::int +1) g 
	group by i
	) foo
,lateral unnest(x) with ordinality t(y,ord);


то же -- про jsonb_agg --для широких еав--ов мне нужно ,аггрегируя, аппендить поля объектов, а не набирать тупо массивы джейсонов--атрибутов.
пока приходится аппендить ключи и значения отдельно, потом пересобирать объект из массивов текстовок. (если бы сразу копить в jsonb-- объекте -- обходилось бы оно алгоритмистски дешевле ?)
26 авг 17, 09:49    [20750770]     Ответить | Цитировать Сообщить модератору
 Re: Голосуем за новые фичи PG  [new]
p2.
Member

Откуда:
Сообщений: 523
qwwq
нужен array_agg(anyarray) AS append
?
create aggregate array_agg_append(integer[]) (
  sfunc=array_cat,
  stype=int4[]
);
28 авг 17, 12:35    [20753299]     Ответить | Цитировать Сообщить модератору
 Re: Голосуем за новые фичи PG  [new]
qwwq
Member

Откуда:
Сообщений: 2277
p2.
qwwq
нужен array_agg(anyarray) AS append
?
create aggregate array_agg_append(integer[]) (
  sfunc=array_cat,
  stype=int4[]
);

неееееееееееееееее
там одних переприсовений будет каак

хочу как положено, копить, а не перекладывать

CREATE AGGREGATE array_agg_append(anyarray) (
  SFUNC=array_agg_array_append_transfn,
  STYPE=internal,
  FINALFUNC=array_agg_array_append_finalfn
);
28 авг 17, 17:02    [20754319]     Ответить | Цитировать Сообщить модератору
 Re: Голосуем за новые фичи PG  [new]
ОКТОГЕН
Member

Откуда:
Сообщений: 2479
В команде REINDEX
в секциях параметра DATABASE и SYSTEM
можно указать только текущую базу.
Смысл её указывать?
Логичнее было бы по-умолчанию не указывать, а если пользователь указал,
то обрабатывать то, что он указал(другую базу на кластере).
Такая идея озвучивалась? Если нет - куда лучше отписаться?
30 авг 17, 12:41    [20758419]     Ответить | Цитировать Сообщить модератору
 Re: Голосуем за новые фичи PG  [new]
qwwq
Member

Откуда:
Сообщений: 2277
qwwq,

придумал хотеть limit в агрегатах. через лейтералы собирается, но когда по многим сортировкам топы в одной записи собираешь -- дюже много писать приходится.
для анализов удобно
14 сен 17, 21:59    [20797350]     Ответить | Цитировать Сообщить модератору
Топик располагается на нескольких страницах: 1 2 3 4 5 6      [все]
Все форумы / PostgreSQL Ответить