еще раз для тех кто в танке. постгре вычисляет какой индекс зайдет лучше. его и юзает

причем в поиск загребется и то где время не нужное.

Но как объянить, что по этому индексу, если выборка происходит, то довольно быстро? Я вообще думал, что составной индекс в данном случае будет рабоать лучше, потому что условно говоря будет тот же самый временной, но не по всему множеству записей, а по сильно ограниченному.

индекс время-тип пробовали? :)

Не пробовал, но пока не понимаю, как он вообще может помощь, мне кажется это тоже самой, что индекс только времени, только с лишними данными

Но как объянить, что по этому индексу, если выборка происходит, то довольно быстро? Я вообще думал, что составной индекс в данном случае будет рабоать лучше, потому что условно говоря будет тот же самый временной, но не по всему множеству записей, а по сильно ограниченному.

может быть вам посмотреть в сторону partial index-а?

может быть вам посмотреть в сторону partial index-а?

Если я правильно понимаю, мой индекс как раз и был partial, ведь там было условие object_type <> ‘type1’. Я еще пробовал создать индекс where object_type=‘type2’ ( интересуемый меня тип ), но это не изменило ситуацию. Возможно, конечно, что я где-то в процессе делал ошибки или забывал запускать команду Analyze, для исключения этого надо будет еще раз все телодвижения повторить

Если я правильно понимаю, мой индекс как раз и был partial, ведь там было условие object_type <> ‘type1’. Я еще пробовал создать индекс where object_type=‘type2’ ( интересуемый меня тип ), но это не изменило ситуацию. Возможно, конечно, что я где-то в процессе делал ошибки или забывал запускать команду Analyze, для исключения этого надо будет еще раз все телодвижения повторить

а в запросе есть object_type <> ‘type1’?

есть object_type = ‘type2’

а если дописать object_type <> ‘type1’ and object_type = ‘type2’?

попробую

спасибо

вообще, вот например в постгисе всё иногда плохо с эстимациями

и нужный план там иногда можно получить методом where (a.geom && b.geom) and (a.geom && b.geom)

Всем привет. Подскажите, как вы решаете подобные задачи: Есть индекс, используемый очень редко, но все-же используемый. Весит много, в связи с объемом таблицы - хорошо бы его похерить. Найти какой именно запрос и какой именно кусок приложения его юзает не удалось ни в коде, ни в pg_stat_statements. Можно ли как-то по - человечески узнать, какой именно запрос заставляет планировщик дергать данный индекс?

Привет! Кто может немножко помочь с pgool? Есть две ноды postgresql в разных городах. Настроена нативная репликация (master/slave). Если одну ноду добавить в рядом расположенный pgpool, все хорошо. Если добавить вторую(slave в другой стране) - все начинает очень тормозить. Вопрос-почему?

Всем привет. Подскажите, как вы решаете подобные задачи: Есть индекс, используемый очень редко, но все-же используемый. Весит много, в связи с объемом таблицы - хорошо бы его похерить. Найти какой именно запрос и какой именно кусок приложения его юзает не удалось ни в коде, ни в pg_stat_statements. Можно ли как-то по - человечески узнать, какой именно запрос заставляет планировщик дергать данный индекс?

грохнуть и смотреть в логе медленных запросов

и нужный план там иногда можно получить методом where (a.geom && b.geom) and (a.geom && b.geom)

Ккй кшмр

Привет! Кто может немножко помочь с pgool? Есть две ноды postgresql в разных городах. Настроена нативная репликация (master/slave). Если одну ноду добавить в рядом расположенный pgpool, все хорошо. Если добавить вторую(slave в другой стране) - все начинает очень тормозить. Вопрос-почему?

Сетевые проблемы? Бывает ли, что слейв убегает от мастера? Что в логах PGPool в момент тормозов?

С сетью все хорошо. Да и пусть убегает(отстает максимум на 3 сек), на slave не должны запросы идти. В логах ничего интересного(

Всем привет. Подскажите, как вы решаете подобные задачи: Есть индекс, используемый очень редко, но все-же используемый. Весит много, в связи с объемом таблицы - хорошо бы его похерить. Найти какой именно запрос и какой именно кусок приложения его юзает не удалось ни в коде, ни в pg_stat_statements. Можно ли как-то по - человечески узнать, какой именно запрос заставляет планировщик дергать данный индекс?

Может стоить посмотреть в сторону auto_explain. Потом через grep по имени индекса поискать в логах, вдруг пишется

Да, спасибо, попробую грохнуть его и отследить запрос.

А кто использовал в качестве хранилища для холодных партиций NFS шару? И вообще это не убьёт БД если шара например отвалится или не примонтируется при старте сервака?

А кто использовал в качестве хранилища для холодных партиций NFS шару? И вообще это не убьёт БД если шара например отвалится или не примонтируется при старте сервака?

Не лучше ли будет использовать FDW?

Не лучше ли будет использовать FDW?

не на всякий NAS постгрес поставишь

Не лучше ли будет использовать FDW?

может и лучше, но у меня ресурсы только такие.

А кто использовал в качестве хранилища для холодных партиций NFS шару? И вообще это не убьёт БД если шара например отвалится или не примонтируется при старте сервака?

можно просто обычную табличку создать в nfs и посмотреть что происходит

не на всякий NAS постгрес поставишь

тоже верно

доступ только через NFS, там бекапы храним. Думал может и холодные данные туда же запихнуть в отдельный tablespace. Чтобы не делать бекапы этих партиций.

а если чтото размонтируется или ктото свич дернет?

если такое и творить, то я бы делал отдельный постгрес для NFS и отдельный для остального

есть подозрение что бд пизданецо

есть подозрение что бд пизданецо

Вот и я думаю тоже. Ладно будем тогда скидывать бекапы партиций, и дропать на БД.

я б на другой сервер партиции кидал

возможно будет ругаться, что каннот рид блок № такой-то. Вряд ли при этом упадет весь клястер

возможно будет ругаться, что каннот рид блок № такой-то. Вряд ли при этом упадет весь клястер

инпут-аутпут еррор иногда складывает постгрес

Не буду экперименты ставить всё таки это прод )

из наших сегодняшних логов вот: [2017-08-24 09:49:39] ERROR: could not read block 4325446 in file "pg_tblspc/16400/PG_10_201707211/16402/782904863.33": Input/output error [2017-08-24 09:49:39] server closed the connection unexpectedly [2017-08-24 09:49:39] This probably means the server terminated abnormally [2017-08-24 09:49:39] before or while processing the request. [2017-08-24 09:49:39] no connection to the server [2017-08-24 09:49:39] connection to server was lost

из наших сегодняшних логов вот: [2017-08-24 09:49:39] ERROR: could not read block 4325446 in file "pg_tblspc/16400/PG_10_201707211/16402/782904863.33": Input/output error [2017-08-24 09:49:39] server closed the connection unexpectedly [2017-08-24 09:49:39] This probably means the server terminated abnormally [2017-08-24 09:49:39] before or while processing the request. [2017-08-24 09:49:39] no connection to the server [2017-08-24 09:49:39] connection to server was lost

xfs ?

нет, у нас своя атмосфера

диск сбойнул?

файлики покорраптили

из наших сегодняшних логов вот: [2017-08-24 09:49:39] ERROR: could not read block 4325446 in file "pg_tblspc/16400/PG_10_201707211/16402/782904863.33": Input/output error [2017-08-24 09:49:39] server closed the connection unexpectedly [2017-08-24 09:49:39] This probably means the server terminated abnormally [2017-08-24 09:49:39] before or while processing the request. [2017-08-24 09:49:39] no connection to the server [2017-08-24 09:49:39] connection to server was lost

хм, уже 10-ку используете?

кажется, да

вкусности ещё, правда, не опробовали

кажется, да

уже на проде?

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

10 катить (потому что круглая), а 11 - вколачивать?))

ребята накидайте несколько годных способов редактирования больших файлов (десятки/сотни ГБ)

А что будете изменять?

ребята накидайте несколько годных способов редактирования больших файлов (десятки/сотни ГБ)

dd ?

vim

sed -i ?

grep + sed

sed вот тоже говорят неплох +1

что еще кроме этого

emacs

emacs

падсталом.

А что будете изменять?

текст

лан, ничего нового похоже нет

emacs

winword ;)

winword ;)

тогда уж сразу notepad.exe

ребята накидайте несколько годных способов редактирования больших файлов (десятки/сотни ГБ)

Такие большие файлы нужно или предварительно нарезать split-ом и править обычными редакторами, или писать скриптик для потокового редактирования.

ERROR: S client not available

Коллеги, добрый день, кто может объяснить момент по рекурсивным запросам?

Вы задавайте вопрос, а вам кто сможет - поможет

Коллеги, добрый день, кто может объяснить момент по рекурсивным запросам?

Сразу пишите проблему

Мне не понятно, что означают "аргументы" в скобках после BRANCH, WITH RECURSIVE BRANCH(IDPARENTCATEGORY, IDCATEGORY, LEVEL) AS (...). В доках про это ничего не написано. А пытаюсь я решить следующую задачу: есть таблица-"дерево" с полями id, tree_node_id и другими информационными. Нужно выбрать всех родителей по заданному id. Рабочий запрос получился таким: WITH RECURSIVE tree_nodes_rec AS ( SELECT id, tree_node_id, name FROM tree_nodes WHERE id=29 UNION SELECT tn.id, tn.tree_node_id, tn.name FROM tree_nodes_rec AS tnr, tree_nodes AS tn WHERE tn.id = tnr.tree_node_id ) SELECT * FROM tree_nodes_rec; Я ищу способ перенести WHERE id=29 в последний селект, чтобы получить SELECT * FROM tree_nodes_rec WHERE id=29; возможно ли так сделать или я трачу время впустую?

Мне не понятно, что означают "аргументы" в скобках после BRANCH, WITH RECURSIVE BRANCH(IDPARENTCATEGORY, IDCATEGORY, LEVEL) AS (...). В доках про это ничего не написано. А пытаюсь я решить следующую задачу: есть таблица-"дерево" с полями id, tree_node_id и другими информационными. Нужно выбрать всех родителей по заданному id. Рабочий запрос получился таким: WITH RECURSIVE tree_nodes_rec AS ( SELECT id, tree_node_id, name FROM tree_nodes WHERE id=29 UNION SELECT tn.id, tn.tree_node_id, tn.name FROM tree_nodes_rec AS tnr, tree_nodes AS tn WHERE tn.id = tnr.tree_node_id ) SELECT * FROM tree_nodes_rec; Я ищу способ перенести WHERE id=29 в последний селект, чтобы получить SELECT * FROM tree_nodes_rec WHERE id=29; возможно ли так сделать или я трачу время впустую?

Это не аргументы, это шапка таблицы временной

если бы ее не было, нельзя было бы обращаться по имени к результатам предыдущих итераций

если бы ее не было, нельзя было бы обращаться по имени к результатам предыдущих итераций

Благодарю, это понял

Мне не понятно, что означают "аргументы" в скобках после BRANCH, WITH RECURSIVE BRANCH(IDPARENTCATEGORY, IDCATEGORY, LEVEL) AS (...). В доках про это ничего не написано. А пытаюсь я решить следующую задачу: есть таблица-"дерево" с полями id, tree_node_id и другими информационными. Нужно выбрать всех родителей по заданному id. Рабочий запрос получился таким: WITH RECURSIVE tree_nodes_rec AS ( SELECT id, tree_node_id, name FROM tree_nodes WHERE id=29 UNION SELECT tn.id, tn.tree_node_id, tn.name FROM tree_nodes_rec AS tnr, tree_nodes AS tn WHERE tn.id = tnr.tree_node_id ) SELECT * FROM tree_nodes_rec; Я ищу способ перенести WHERE id=29 в последний селект, чтобы получить SELECT * FROM tree_nodes_rec WHERE id=29; возможно ли так сделать или я трачу время впустую?

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

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

Я тут нагуглил, что https://stackoverflow.com/a/27860315/3134155 можно создать view как в этом ответе, но я не до конца понимаю как во view передаётся условие

можно сделать функцию и вынести значение (29) в аргументы

хорошая идея. А в конце концов сработает ли подстановка в этом запросе? WITH RECURSIVE tree_nodes_rec AS (... WHERE id=$1...) ...;

Ну это на случай если не мудрить и оставить как есть.

Я тут нагуглил, что https://stackoverflow.com/a/27860315/3134155 можно создать view как в этом ответе, но я не до конца понимаю как во view передаётся условие

А в этом примере условие никуда особо и не передается, оно применяется сверху к CTE (https://explain.depesz.com/s/imd6), то есть фильтруется уже результат.

срабатывают обычные rewrite rules для view

http://sqlfiddle.postgrespro.ru/#!17//1320

Примерно понятно, спасибо

Кому интересно: WITH RECURSIVE tree_nodes_rec(idbr, tree_node_id, name, woof) AS ( SELECT id AS idbr, tree_node_id, name, false AS woof FROM tree_nodes UNION ALL SELECT tnr.idbr, tn.tree_node_id, tn.name, NOT woof FROM tree_nodes_rec AS tnr, tree_nodes AS tn WHERE tn.id = tnr.tree_node_id ) SELECT idbr, tree_node_id, name, woof FROM tree_nodes_rec WHERE idbr=29; Вот как разрешилось

Кому интересно: WITH RECURSIVE tree_nodes_rec(idbr, tree_node_id, name, woof) AS ( SELECT id AS idbr, tree_node_id, name, false AS woof FROM tree_nodes UNION ALL SELECT tnr.idbr, tn.tree_node_id, tn.name, NOT woof FROM tree_nodes_rec AS tnr, tree_nodes AS tn WHERE tn.id = tnr.tree_node_id ) SELECT idbr, tree_node_id, name, woof FROM tree_nodes_rec WHERE idbr=29; Вот как разрешилось

если у вас большая таблица tree_nodes, это будет не эффективно

Насколько большая? В принципе в ней простые менюшки, каталоги магазина (отсилы 100-200 позиций)

а как обычно поступают тогда, чтобы повысить эффективность?

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

чем меньше строк окажется в рабочей таблице после нулевой итерации, тем лучше

https://postgrespro.ru/docs/postgrespro/9.6/queries-with

см. Вычисление рекурсивного запроса

Все, разобрался, огромнейшая благодарность

тогда уж сразу notepad.exe

Вот вы смеетесь а волковкоммандер умел оочень большие файлы редактировать например. Во времена когда "640 кб хватит на всё" приходилось выкручиваться

Ну как большие, в досе то

Вот вы смеетесь а волковкоммандер умел оочень большие файлы редактировать например. Во времена когда "640 кб хватит на всё" приходилось выкручиваться

но в цитируемой шутке речь-то шла о Ворде, а не Волкове)

Вот вы смеетесь а волковкоммандер умел оочень большие файлы редактировать например. Во времена когда "640 кб хватит на всё" приходилось выкручиваться

Ему и хватало

Ему и хватало

Особенно если мышку не подгружать )