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

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

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


log_min_duration_statement = 0


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

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

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

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

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

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

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

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

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


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

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

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

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

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

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

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

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

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

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

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



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

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

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

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


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

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


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

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


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

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

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

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

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

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

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

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

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