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

Откуда:
Сообщений: 2359
не нашол в предложениях
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

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

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

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

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

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

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

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

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