Size: a a a

pgsql – PostgreSQL

2021 March 09

A

Alex in pgsql – PostgreSQL
@livinbelievin я наверное через запрос всего и на бекенде разрулю эти интервалы, хз, не гуглится)
источник

A

Alex in pgsql – PostgreSQL
Alex
не, задача немного в другом состоит
пользователь, находясь на странице, через js шлет запросы, что я такой-то uid, нахожусь на такой-то странице в такое-то время
шлет он это раз в 10 секунд (условно)
тут нет события "я пришел на страницу" и "я ушел со страницы"
мне надо узнать промежутки, когда пользователь посещал вот эту конкретную страницу, сколько он провел на ней времени
то есть первая запись появилась в 9.00 утра, а последняя запись с 10 секундным интервалом засветилась в 10.00, а потом пользователь опять начал отсылать запросы в 11.00 - это уже другой период надо записывать
ну разве что Yaroslav подскажет какое-нибудь решение)
источник

s

sexst in pgsql – PostgreSQL
Gonchik Tsymzhitov
  Gather  (cost=1000.57..708213.47 rows=599273 width=34) (actual time=0.598..2202.731 rows=656324 loops=1)
  Workers Planned: 4
  Workers Launched: 4
  Buffers: shared hit=3296018 read=262261
  ->  Nested Loop  (cost=0.56..647286.17 rows=149818 width=34) (actual time=0.127..2101.260 rows=131265 loops=5)
        Buffers: shared hit=3296018 read=262261
        ->  Parallel Seq Scan on "AO_8542F1_IFJ_OBJ_ATTR" oa  (cost=0.00..423521.28 rows=150508 width=8) (actual time=0.070..1007.676 rows=131265 loops=5)
              Filter: ("OBJECT_TYPE_ATTRIBUTE_ID" = ANY ('{529,10,506,143}'::integer[]))
              Rows Removed by Filter: 7891993
              Buffers: shared hit=10822 read=262261
        ->  Index Scan using index_ao_8542f1_ifj228666017 on "AO_8542F1_IFJ_OBJ_ATTR_VAL" oav  (cost=0.56..1.48 rows=1 width=42) (actual time=0.008..0.008 rows=1 loops=656324)
              Index Cond: ("OBJECT_ATTRIBUTE_ID" = oa."ID")
              Buffers: shared hit=3285196
Planning time: 0.431 ms
Execution time: 2225.289 ms
(15 rows)


не помог,


                                  Table "public.AO_8542F1_IFJ_OBJ_ATTR"
         Column          |  Type   |                               Modifiers
--------------------------+---------+-----------------------------------------------------------------------
ID                       | bigint  | not null default nextval('"AO_8542F1_IFJ_OBJ_ATTR_ID_seq"'::regclass)
OBJECT_ID                | integer |
OBJECT_TYPE_ATTRIBUTE_ID | integer |
UPDATED                  | bigint  |
Indexes:
   "AO_8542F1_IFJ_OBJ_ATTR_pkey" PRIMARY KEY, btree ("ID")
   "index_ao_8542f1_ifj268009346" btree ("OBJECT_TYPE_ATTRIBUTE_ID")
   "index_ao_8542f1_ifj43488772" btree ("OBJECT_ID")
   "index_ao_insight_2" btree ("ID") WHERE "OBJECT_TYPE_ATTRIBUTE_ID" = ANY (ARRAY[529, 10, 506, 143])
Foreign-key constraints:
   "fk_ao_8542f1_ifj_obj_attr_object_id" FOREIGN KEY ("OBJECT_ID") REFERENCES "AO_8542F1_IFJ_OBJ"("ID")
   "fk_ao_8542f1_ifj_obj_attr_object_type_attribute_id" FOREIGN KEY ("OBJECT_TYPE_ATTRIBUTE_ID") REFERENCES "AO_8542F1_IFJ_OBJ_TYPE_ATTR"("ID")
Referenced by:
   TABLE ""AO_8542F1_IFJ_OBJ_ATTR_VAL"" CONSTRAINT "fk_ao_8542f1_ifj_obj_attr_val_object_attribute_id" FOREIGN KEY ("OBJECT_ATTRIBUTE_ID") REFERENCES "AO_8542F1_IFJ_OBJ_ATTR"("ID")



в плане, памяти,
 
             total        used        free      shared  buff/cache   available
Mem:          24947        2118         207        5803       22620       16659
Swap:          3071           0        3071
Total:        28019        2118        3279


max_wal_size = 4GB
min_wal_size = 1GB
checkpoint_completion_target = 0.7
effective_io_concurrency = 200          # 1-1000; 0 disables prefetching
max_worker_processes = 8                # (change requires restart)
max_parallel_workers_per_gather = 4
work_mem = 8987kB
maintenance_work_mem = 1408MB
shared_buffers = 6240MB


временно добавлял
ALTER SYSTEM SET shared_buffers = '10GB';
А, ну вот, почти вся оперативка и так под файловый кэш ушла в системе. Похоже не хватает её на хранение всех горячих данных и эта таблица вытесняется быстро оттуда.
Почему планировщик так решает и какие оценки у других планов это отдельный вопрос.
источник

YS

Yaroslav Schekin in pgsql – PostgreSQL
Alex
типа того, да
Так это одна из "стандартных" задач "gaps and islands", на первый взгляд... нет?
источник

A

Alex in pgsql – PostgreSQL
не исключено, если бы я знал, что это такое 😄
источник

s

sexst in pgsql – PostgreSQL
Alex
не, задача немного в другом состоит
пользователь, находясь на странице, через js шлет запросы, что я такой-то uid, нахожусь на такой-то странице в такое-то время
шлет он это раз в 10 секунд (условно)
тут нет события "я пришел на страницу" и "я ушел со страницы"
мне надо узнать промежутки, когда пользователь посещал вот эту конкретную страницу, сколько он провел на ней времени
то есть первая запись появилась в 9.00 утра, а последняя запись с 10 секундным интервалом засветилась в 10.00, а потом пользователь опять начал отсылать запросы в 11.00 - это уже другой период надо записывать
Я так понимаю, что в каждой строке записывается не только отметка времени, но и куча других столбцов с какими-то изменяющимися данными?
Интересуюсь потому что в случае таблицы из одних временных отметок (или с неизменными дополнительными полями), я бы записывал время начала сессии в один столбец, а потом, при приходе новых сообщений, смотрел сколько секунд прошло с момента прошлой отметки и обновлял бы второй столбец с временем конца сессии или же писал в новую строку как время старта другой сессии.
источник

A

Alex in pgsql – PostgreSQL
sexst
Я так понимаю, что в каждой строке записывается не только отметка времени, но и куча других столбцов с какими-то изменяющимися данными?
Интересуюсь потому что в случае таблицы из одних временных отметок (или с неизменными дополнительными полями), я бы записывал время начала сессии в один столбец, а потом, при приходе новых сообщений, смотрел сколько секунд прошло с момента прошлой отметки и обновлял бы второй столбец с временем конца сессии или же писал в новую строку как время старта другой сессии.
Есть доп поля, да, но непринципиально, предлагаете через триггер и доп таблицу?
источник

s

sexst in pgsql – PostgreSQL
Я бы старался как-то это компактизировать при записи, да. Сессии записывать интервалами начало-конец, доп. поля записывать в другой таблице и только если значения в каком-то из них изменилось относительно прошлого. Потому что в общем и целом записи про каждого пользователя каждые 10 секунд мне видятся прямой дорогой к огромной таблице в недалёком будущем.
Хотя может вы последние сутки только храните, такие подробности нам неизвестны.
источник

YS

Yaroslav Schekin in pgsql – PostgreSQL
Alex
не исключено, если бы я знал, что это такое 😄
google знает. ;)
А иначе — покажите sqlfiddle, "абстрактно" подсказывать как-то не очень удобно.
источник

А

Антон in pgsql – PostgreSQL
Доброго времени суток!
Сабж: у меня NPgSql и Dapper. Также на машине стоит Devart DotConnect.
Во всех примерах вижу передачу параметров через @, однако у меня работает и через :
Вопрос: это уже переделано, что работает через : или у меня каким-то чудом работа идёт через dotConnect ?
Заранее спасибо.
источник

L

Les in pgsql – PostgreSQL
#вакансия #wildberries #удаленка
Позиция: dba
Условия 150-200 тр на руки

Предстоящие задачи :
* Поддержка и обслуживание БД postgres, clickhouse
* Организация отказоустойчивости
* Развёртывание сред с использованием ansible
* Тестирование и применение Best practices самостоятельно и совместно с командой
* Регулярный апгрейд СУБД на новые версии

Обязательно:
* Опыт администрирования Postgres от 1 года
* Знание Linux(метрики производительности, работа в консоли)
* Представление о подхода к хранению данных
* Знание механизмов репликации
* Опыт настройки репликации
* Хорошее знание SQL
* Умение разбираться в чужом коде

Будет плюсом:
* Опыт использования ansible
* Опыт использования docker / kubernetes
* Знание механизмов service-discovery и service-mesh
* Знание систем мониторинга и опыт настройки
* Практический опыт с общеизвестными кластерными решениями
* Опыт разработки на любом ЯП
источник

VY

Victor Yegorov in pgsql – PostgreSQL
Les
#вакансия #wildberries #удаленка
Позиция: dba
Условия 150-200 тр на руки

Предстоящие задачи :
* Поддержка и обслуживание БД postgres, clickhouse
* Организация отказоустойчивости
* Развёртывание сред с использованием ansible
* Тестирование и применение Best practices самостоятельно и совместно с командой
* Регулярный апгрейд СУБД на новые версии

Обязательно:
* Опыт администрирования Postgres от 1 года
* Знание Linux(метрики производительности, работа в консоли)
* Представление о подхода к хранению данных
* Знание механизмов репликации
* Опыт настройки репликации
* Хорошее знание SQL
* Умение разбираться в чужом коде

Будет плюсом:
* Опыт использования ansible
* Опыт использования docker / kubernetes
* Знание механизмов service-discovery и service-mesh
* Знание систем мониторинга и опыт настройки
* Практический опыт с общеизвестными кластерными решениями
* Опыт разработки на любом ЯП
посмотрите описание группы, там ссылка на канал для вакансий
источник

IK

Ilshat Karazbaev in pgsql – PostgreSQL
Victor Yegorov
посмотрите описание группы, там ссылка на канал для вакансий
так мало людей там, мало кто в курсе
источник

VY

Victor Yegorov in pgsql – PostgreSQL
Ilshat Karazbaev
так мало людей там, мало кто в курсе
я согласен. но тут могут счесть за оффтопик.
источник

EF

Eugene Freeman in pgsql – PostgreSQL
with max_salary_table as (
   SELECT Employee.name,
          D.name as name_company,
          Employee.salary,
          dense_rank() OVER (PARTITION BY Employee.departmentId order by salary DESC) as rating
   from Employee
            join Department D on D.id = Employee.departmentId
)
select name, name_company, salary
from max_salary_table
where rating = 1;

ребятки, можно как-то упростить запрос?
источник

EF

Eugene Freeman in pgsql – PostgreSQL
задача простая, поиск сотрудников получающих макс зп по депортаментам
источник

VY

Victor Yegorov in pgsql – PostgreSQL
Eugene Freeman
задача простая, поиск сотрудников получающих макс зп по депортаментам
DISTINCT ON. но не факт, что это будет самый быстрый результат в любой ситуаци
источник

EF

Eugene Freeman in pgsql – PostgreSQL
интересует варинат решения с использованием оконных функций
источник

А

Антон in pgsql – PostgreSQL
Eugene Freeman
with max_salary_table as (
   SELECT Employee.name,
          D.name as name_company,
          Employee.salary,
          dense_rank() OVER (PARTITION BY Employee.departmentId order by salary DESC) as rating
   from Employee
            join Department D on D.id = Employee.departmentId
)
select name, name_company, salary
from max_salary_table
where rating = 1;

ребятки, можно как-то упростить запрос?
а having salary=max(salary) не подойдёт?
источник

EF

Eugene Freeman in pgsql – PostgreSQL
подойдет, но интересно можно ли сделать с window function
источник