Телеграмм чат группы pgsql страница 13353

у нас squirrel, я фиг знает, что у него под капотом.
спасибо большое за подсказку!

12:26пожаловаться #1

Yaroslav Schekin in pgsql – PostgreSQL

> у нас из-за таких больших запросов коннекты обрываются.

Но почему? В норме этого не должно происходить.

> в этом проблема. ресурсы не безграничны.

И, ещё раз, "стремление" любой СУБД использовать их "на всю катушку" — это нормально, понимаете?

> и отваливаются коннекты к бд из-за этого.

Что такое "отваливаются"? Где / как / с какой ошибкой?

12:28пожаловаться #2

Фу фу фу, orm в go зло, особенно на таких объемах. Ну в данном случае можно и написать на pgx и SQL. Или в магаз за дисками.

12:28пожаловаться #3

Yaroslav Schekin in pgsql – PostgreSQL

Способ для чего именно? Т.е. тут от ситуации зависит, вряд ли можно что-то "в общем" посоветовать.

12:29пожаловаться #4

Это мое личное мнение.

12:29пожаловаться #5

Yaroslav Schekin in pgsql – PostgreSQL

А секция откуда будет читаться, извините? Или это "волшебная пыль", которая позволяет получать данные, не читая их? ;)

12:30пожаловаться #6

pgbouncer cannot connect to server (SQLSTATE 08P01) и pgbouncer cannot connect to server (SQLSTATE 08P01)

по идее, баунсер просто ждет своей очереди, если коннектов не хватает. и кидает ошибки

12:30пожаловаться #7

Alexey Bulgakov in pgsql – PostgreSQL

разбить например на 10 секций и читаться будет нужная секция т.е. 1/10. в том числе и с индексами локальными будет быстрее работа. вопрос в ключе секционирования

12:31пожаловаться #8

Yaroslav Schekin in pgsql – PostgreSQL

А на сервере при этом что (в логах PostgreSQL)?
Дело в том, что в норме pgbouncer большую часть времени соединения просто "держит", поэтому то, что Вы показываете, необычно.

12:32пожаловаться #9

вот это не подскажу, к серверным логам доступа нет :(

12:33пожаловаться #10

Yaroslav Schekin in pgsql – PostgreSQL

Или [намного] медленнее (если запрос не идеально попадает в секцию).
Т.е. занятия партиционированием с целью повышения производительности запросов нередко (по умолчанию, я бы даже сказал) приводят к обратному эффекту.

12:35пожаловаться #11

Посмотрел. У него под капотом database/sql. По идеи можно использовать pgx. Потому совет рабочий.

12:35пожаловаться #12

Alexey Bulgakov in pgsql – PostgreSQL

я же написал вопрос в ключе секционирования. если он есть оптимальный для всех или почти всех запросов к таблице, то все будет ок. нет, так и не надо секционировать

12:36пожаловаться #13

спасибо. почитаю про go pipeline :)

12:36пожаловаться #14

Go Concurrency Patterns: Pipelines and cancellation - The Go Blog

Вам сюда: https://blog.golang.org/pipelines

blog.golang.org

Go is an open source programming language that makes it easy to build simple, reliable, and efficient software.

12:37пожаловаться #15

благодарю!

12:38пожаловаться #16

Yaroslav Schekin in pgsql – PostgreSQL

Да, я видел. Я к тому, что партиционирование — это целое дело (нужно планировать, создавать это всё, "переливать" данные — скорее всего, с downtime)... чтобы "в награду", даже если всё будет идеально, получить... что? На 10-20% более высокую производительность по сравнению с индексом, который создать тривиально? ;)

12:39пожаловаться #17

Alexey Bulgakov in pgsql – PostgreSQL

так если индекс ему поможет, то ради бога :) вы уверены что индекса будет достаточно?

12:40пожаловаться #18

Yaroslav Schekin in pgsql – PostgreSQL

Достаточно для чего?
Там же вообще непонятно, какая именно проблема — это просто обсуждения "вокруг да около". ;)

12:41пожаловаться #19

Одно понятно что проблема не в БД)