9404
Чат русскоязычного сообщества PostgreSQL, здесь мы обсуждаем технические вопросы, для поиска работы и предложения вакансий есть группа https://t.me/pgsqljobs For English discussion visit https://t.me/pg_sql
но вообще это странное требование, запретить временные таблицы по моему никак не получится, только организационно
Читать полностью…
Оу, теперь ясно, а раз полностью запрещают, значит и контрить особо нечем, кроме прямой работы со схемой, ясно-понятно.
Спасибо!
временная таблица перекрывает любую другую существующую
create table users(name text, is_root bool); insert into users values ('vasya', false);
select * from users where name = 'vasya';
name | is_root
-------+---------
vasya | f
create temp table users (name, is_root) as select 'vasya', true;
SELECT 1
select * from users where name = 'vasya';
name | is_root
-------+---------
vasya | t
если работать без указания схемы то можно словить интересные спецэффекты =)
Читать полностью…
Коллеги, я изначально совсем не БД, поэтому сильно не бейте за нубский вопрос :)
От безы есть требования при работе с постгрей обходится без временных таблиц совсем.
Само требование не проблема, но есть желание понять, что ИБшники не любят в temporary tables настолько, что совсем их запрещают, может кто поделится мудростью?
потому что limit напрямую влияет на оценку rows %)
Читать полностью…
Я помню! Просто вдруг что-то широко известное.
Слишком уж много всего копипастить придётся
да, есть такое, надо одинаковую волатильность делать
Читать полностью…
explain (analyze, verbose) with cte1 as (select usename from pg_user) select usename, (select count(*) from cte1) from cte1;
QUERY PLAN
-------------------------------------------------------------------------------------------------------------------------
CTE Scan on cte1 (cost=1.62..1.88 rows=13 width=72) (actual time=0.027..0.031 rows=14 loops=1)
Output: cte1.usename, $1
CTE cte1
-> Seq Scan on pg_catalog.pg_authid (cost=0.00..1.32 rows=13 width=64) (actual time=0.011..0.015 rows=14 loops=1)
Output: pg_authid.rolname
Filter: pg_authid.rolcanlogin
Rows Removed by Filter: 19
InitPlan 2 (returns $1)
-> Aggregate (cost=0.29..0.30 rows=1 width=8) (actual time=0.012..0.012 rows=1 loops=1)
Output: count(*)
-> CTE Scan on cte1 cte1_1 (cost=0.00..0.26 rows=13 width=0) (actual time=0.000..0.008 rows=14 loops=1)
Output: cte1_1.usename
Query Identifier: 7233659122161546696
Planning Time: 0.142 ms
Execution Time: 0.059 ms
(15 rows)
сделать свою функцию с raise notice и посмотреть сколько раз notice сработает :-)
больше наверное никак
в чём вообще ситуация. Я спорил с человеком, что не надо писать запрос вида
with cte1 as (select id, name from user )
select a, (select count(*) from cte1) from cte1;
select id, name from user select count(*) from user
Может, я что-то не понимаю
Если движок сто раз вызвал аггрегатную функцию, может ли это происходить в рамках одного узла?
Почему добавление к запросу
LIMIT 10превращает вполне приличный Index Scan по object_id в невероятно долгий Index Scan Backward по date_action ? Читать полностью…
Привет) Дайте идеи?
Есть строка типа 'random_word123 (t45.column) another67_word t890 000word'
Нужно вытащить оттуда числа 45 из 't45' и 890 из 't890'
Запретить технически наверное нет, но все сесси пишутся и анализируются, соответственно к нарушителям применяются именно оргметоды
Читать полностью…
Принял, спасибо.
Ну, уточнения мы ждём, но они люди занятые)
Не знаю что такое постгрей, но в любом случае стоит попросить безопасников обосновать данный пункт - либо они хотят сделать невозможным какой-то вектор атаки, либо они хотят иметь возможность смотреть все таблицы в системе (правда, непонятно зачем это нужно).
Читать полностью…
П.2 в любом случае придётся обрабатывать. Т.е., игнорировать/перезаписывать существующую запись с емайл пользователя, если по ней истёк срок проверки и она не подтверждена.
Читать полностью…
upd. больше не подскажу - банально нет опыта.
Читать полностью…
если бы тут был Ярослав или Илья, то он попросил бы данные по плану и схеме из закрепа.
потом напомнили бы про vacuum analyze.
и сказали бы, что дело скорее всего в early abort plan, кореллирующих столбцах, плохом распределении данных или чём-нибудь подобном.
там же надо прописывать функции какие-то иммутабл свойства, чтобы движок пг не решил, что фукнцию надо выполнять каждый раз. И не получилось, что встроенный count() считает один раз за весь запрос, а самописная функция с count() считает для каждой строки
Так можно офигенно намерить ))
точно. Я читал об этом в книге от packt'а, но это настолько травматичная информация, что моя память вытеснила это
Читать полностью…
поэтому вопрос - если все вызовы функции в запросе пг считает за один луп, как посчитать, сколько раз он эту функцию вызывал?
Читать полностью…
типа того, движок вызвал один раз узел и сказал ему какую функцию вызывать (sum) и на каких данных, поэтому loop=1 так как loop относится к узлу, а не к функции
Читать полностью…
Так для каждой строки же отдельно надо считать, нет? Как за один раз можно посчитать нарастающей сумму для каждой строки в наборе?
Ну, допустим, они отсортированы, и ты не суммируешь все предыдущие строки со значением из текущей строки, а просто складываешь значение из предыдущей строки со значением из текущей. Всё равно тебе надо делать SUM (ну или операцию сложения из функции SUM) для каждой строки, потому что ты заранее не можешь предугадать, что в ней
loop это сколько раз узел этот вызывался, sum over можно же за один проход подсчитать, если данные на вход подаются отсортированно как нужно, а они как раз так и подаются
Читать полностью…
https://www.postgresql.org/docs/16/functions-string.html
Читать полностью…
Если у меня в этом сообщении была гипотеза, что count может заранее просчитать значения по сорту, и поэтому за один раз посчитал все строки — то сейчас я поменял способ наполнения таблицы и аггрегатный оператор на SUM, и вообще не понимаю почему на 100 тысяч строк всего 1 loop WindowAgg
подготовка таблицы:
do $$
begin
for i in 0..100000 loop
insert into tbl(a) select floor( random() * 100000);
end loop;
end
$$ language plpgsql