Добро пожаловать в форум, Guest  >>   Войти | Регистрация | Поиск | Правила | В избранное | Подписаться
Все форумы / PostgreSQL Новый топик    Ответить
Топик располагается на нескольких страницах: Ctrl  назад   1 2 [3] 4 5 6   вперед  Ctrl      все
 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]     Ответить | Цитировать Сообщить модератору
Топик располагается на нескольких страницах: Ctrl  назад   1 2 [3] 4 5 6   вперед  Ctrl      все
Все форумы / PostgreSQL Ответить