Так я еще и не нашел - может не ваш вариант

Не торопитесь

Со стороны сервера можно узнать статус соединений с точки зрения системы? И послушать что в них бегает? Может просто файрвол криво вставили

tcp-state у них какой?

И опять-таки - если там 60 сек ничего не бегало - должны закрываться.

Привет! Умеет ли pg_dump сдампить таблицу как 1 большой INSERT вместо кучи мелких?

Привет! Умеет ли pg_dump сдампить таблицу как 1 большой INSERT вместо кучи мелких?

Вероятно лучше использовать COPY

удобней инсерты, таки

удобней инсерты, таки

Удобней всего сначала почитать документацию.

И попытаться понять, почему по-умолчанию pg_dump использует COPY..

INSERT понятен, когда надо в больщом дампе поймать ошибочную строку. И/или загрузить дамп с битой(ми) строкой(ами).

Было у меня такое приключение - из мыскля в пг некоторое количество инфы переливал.

привет. подскажите,можно ли заставить пг использовать индекс? Hash Cond: (c.code = l.countrycode) -> Seq Scan on public.country c (cost=0.00..7.39 rows=239 width=15) (actual time=0.005..0.233 rows=239 loops=1) Output: c.code, c.name, c.continent, c.region, c.surfacearea, c.indepyear, c.population, c.lifeexpectancy, c.gnp, c.gnpold, c.localname, c.governmentform, c.headofstate, c.capital, c.code2

Seq Scan — индекс на нужные поля есть

Seq Scan — индекс на нужные поля есть

сколько записей в таблице всего?

239

в плане стоит

есть подозрение что постгрес на таком количестве не будет индекс использовать :)

быстрее с диска прочитать последовательно

ну в теории всё должно быть в рам. но выбирать даже среди 239 элементов быстрее индексом, чем полным сканом

ну простейшая программа даёт что на массиве больше 3 элементов быстрее дерево/хеш, чем последовательный скан

ну так можно как то убедить пг использовать индекс?

просто даже чтобы проверить

нагуглил set enable_seqscan=false

не знаю правда зачем такой изврат, и поможет ли

согласен что зависит от многих факторов, но 239 точно "достаточно много" чтобы индекс имел смысл

впрочем, итоговое время исполнения не изменилось... :)

согласен что зависит от многих факторов, но 239 точно "достаточно много" чтобы индекс имел смысл

я слышал про число около 8000 записей для оракла

@moveaxeax сенкс.

я правда нуб, не знаю тонкостей таких

офтопный вопрос, а какой самый лучший tool для бекапа всего ванильного Pg?

нужно всю бд забекапить

тестовая программа давала 422-429 запросов в секунду. после отклучения секскан получилось 423. т.е. никаких изменений, хотя по плану видно что секскана больше нет

я вижу что хуже не стало. как и лучше не стало.

не должно было

по логике могло стать хуже

ну как не могло? секскан на то и нужен что он иногда быстрее

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

я понимаю что он иногда быстрее. но в моём случае получилось одинаково

видимо если строк в таблицу добавить, то будет медленнеее

может и получил бы

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

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

в mysql двигло таблицы случайно не myisam?

нагуглил set enable_seqscan=false

нагугли лучше random page cost и secscan page cost

нагугли лучше random page cost и secscan page cost

зачем?

совершенно точно выбранных записей будет сильно меньше 239

зачем?

ну это более нежные крутилки чем запрет вообще какой-то ноды планера

239 записей в таблице. выбираться должно ну штук 15

я показал часть плана, план побольше будет

вот план: https://pastebin.com/F6qiaEFR

WHERE Language = 'English';

это в лефт жойн

и вообще чо вы мозги ебете при 4мс

и вообще чо вы мозги ебете при 4мс

20% хуже мыскл

чем хуже-то? залей лям и сравнивай

это вообще не числа для базы

какой "залей лям"? это сэмпл дб, она уже есть

20% хуже мыскл

ну по одному запросу если и стоит сравнивать, то только если это самый критичный запрос. типа на 20% меньше денег заработаем

это значит на 20% больше ресурсов нужно

если только этот запрос ебашить да

так а почему там лефт джойн к языку?

ну как не могло? секскан на то и нужен что он иногда быстрее

Ты забываешь про время планирования

Ты забываешь про время планирования

должно кешироваться по идее.

т.е. план должен кешироваться

А 200 записей - это странички этак четыре

так а почему там лефт джойн к языку?

для одинаковости, чтобы сравнивать со сгенерированным орм запросом...

а посмотри ради интереса на другой запрос и его план и время

На четырех страницах ничего планировать не надо, их надо просто прочитать, если кост строки не запредельный