Добро пожаловать в форум, 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, Австралия
Сообщений: 3444
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, Австралия
Сообщений: 3444
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, Австралия
Сообщений: 3444
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!!!
Сообщений: 3308
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!!!
Сообщений: 3308
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

Откуда:
Сообщений: 2342
ОКТОГЕН
Валидация функций и расширений
Очень поможет избегать ошибок в критичных приложениях.
У каждой функции при коммите будет проверяться статус, если она 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

Откуда:
Сообщений: 2342
ОКТОГЕН
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

Откуда: Камчатка
Сообщений: 4035
хочу 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

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

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

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

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

Откуда:
Сообщений: 2342
ОКТОГЕН
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!!!
Сообщений: 3308
автор
Как-то всё ладно скроено, по стандартам и предсказуемо.

вот это и надо поддерживать.
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, Австралия
Сообщений: 3444
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

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

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

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

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

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


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

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

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

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

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

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

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

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

Откуда:
Сообщений: 432
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, Австралия
Сообщений: 3444
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, Австралия
Сообщений: 3444
PCContra
Postgres пока (версия 9.5) не умеет сравнивать тип данных JSON друг с другом
ЖДУ.


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

Откуда:
Сообщений: 2342
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, Австралия
Сообщений: 3444
ОКТОГЕН
В 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

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

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

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

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

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

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

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

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

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

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

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

Приделали карту заморозки страниц, в которую смотрит 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

Откуда:
Сообщений: 432
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

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

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

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

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


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

Откуда: Тернопіль, Україна
Сообщений: 2097
очень хочу профайлер как в 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

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

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

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

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

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


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

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

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

Откуда:
Сообщений: 2342
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

Откуда:
Сообщений: 2342
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

Откуда: Камчатка
Сообщений: 4035
до сих пор жду
нормальный, поддерживающий
множественные ограничения
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

Откуда:
Сообщений: 2342
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

Откуда:
Сообщений: 2342
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

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

придумал хотеть limit в агрегатах. через лейтералы собирается, но когда по многим сортировкам топы в одной записи собираешь -- дюже много писать приходится.
для анализов удобно
14 сен 17, 21:59    [20797350]     Ответить | Цитировать Сообщить модератору
 Re: Голосуем за новые фичи PG  [new]
Ролг Хупин
Member

Откуда: Чебаркуль
Сообщений: 1586
Голосуй, не голосуй, а уже в пути

PostgreSQL 11:

SQL procedures

This adds a new object type "procedure" that is similar to a function
but does not have a return type and is invoked by the new CALL statement
instead of SELECT or similar. This implementation is aligned with the
SQL standard and compatible with or similar to other SQL implementations.

This commit adds new commands CALL, CREATE/ALTER/DROP PROCEDURE, as well
as ALTER/DROP ROUTINE that can refer to either a function or a
procedure (or an aggregate function, as an extension to SQL). There is
also support for procedures in various utility commands such as COMMENT
and GRANT, as well as support in pg_dump and psql. Support for defining
procedures is available in all the languages supplied by the core
distribution.

While this commit is mainly syntax sugar around existing functionality,
future features will rely on having procedures as a separate object
type.
6 дек 17, 17:16    [21012007]     Ответить | Цитировать Сообщить модератору
Топик располагается на нескольких страницах: 1 2 3 4 5 6      [все]
Все форумы / PostgreSQL Ответить