ускорить расчёт дистанции индексом не получится, сравнение двух чисел тоже

Вроде работает, только с одним ньюансом, мне еще ранее подобное решение подсказывали, нужно переделать location из geometry в geography

оно никогда не зайдёт в индекс по геометрии, а так да, работает ;)

ST_DWithin

соответственно, эстиматор для ST_DistanceSphere(a, b) < N тоже сходит с ума

и число строк тоже неправильно эстимируется

У меня в общем в поле location хранятся координаты из google maps, если я его переделаю в geography, я могу на какой-нибудь баг напороться потом? Из запросов в основм, взять координаты и отобразить на карте. Взять точки в радиусе, Выбрать точки в полигоне. Вроде всё

зачем тебе geography?

geometry(Point, 4326)

Без него не работает

с ST_DWithin

Не юзается индекс

А так, в целом спасибо

у тебя ж индекс построен по тому, что ты передаёшь агрументом в ST_DWithin, а не по исходному полю, правда? :)

М, не понял, это одно и тоже же

Индекс

CREATE INDEX storagepricingapp_storagelocation_location_id ON public.storagepricingapp_storagelocation USING gist (location);

location я и передаю в ST_Dwithin

Я создал поле loc geography(Point,4326) и по нему делаю запросы с ST_DWithin

а вызов ST_DWithin как выглядит?

И оно быстро работает и индекса вообще нет

что значит "индекса нет", покажи :)

http://dumpz.org/2622815/

Индекс есть по facility_id

ST_DWithin("storagepricingapp_storagelocation"."loc", ST_GeomFromEWKB('\x0101000020e6100000b04cf0ff963f5ac0ad4886eb90dc4340'::bytea), 8046.72, true))

ты передаёшь в сигнатуру для geography - geometry

он сам неявно кастует

Нет, loc - это уже geography

c location - geometry, работает медленее

Вот я и думаю, то ли мне location переделывать в geography, то ли как-то сделать запрос, чтобы всё-таки facility_id индекс юзался

Второе предпочтительнее

Привет, верно ведь что колонка с типом ENUM в таблице, не может быть NULLABLE(postgres)?

проверить самому несложно же

Я проверял, 42804)

Но может есть какой то способо NULL выставить? может как то enum type создавать с поддержкой NULL

аээы.. 9.6: igor=# CREATE TYPE rainbow AS ENUM ('red', 'orange', 'yellow', 'green', 'blue', 'purple'); igor=# CREATE TABLE test (id serial, color rainbow); igor=# INSERT INTO test (id) VALUES (1); igor=# INSERT INTO test (id, color) VALUES (2, NULL); igor=# SELECT count(*) FROM test WHERE color IS NULL; count ------- 2

@iamigor Спасибоо!)

А нет ( You will need to rewrite or cast the expression.

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

Версию сейчас гляну, я ваш повторил)

Amazing, 9.6.2

Напомните плиз по реплиакации master-slave. Slave сервер по ресурасам должен быть похож на мастер или может быть значительно слабее? реплика используется на случай падения мастера.

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

Ребят, силюсь понять синтаксис, но не понимаю. В чём отличие SELECT * FROM a,b WHERE a.id=b.a_id от SELECT * FROM a JOIN b ON a.id=b.a_id

В этом случае они эквивалентны

А в каком нет?

В lateral, например

Или когда джоинов больше, порядок перебора вариантов у планировщика начинается с "делать как написано"

И тогда последний вопрос. (надеюсь не развяжу холивар) А как правильнее?

с джоинами

Правильнее - чтобы было не больно читать

Правильнее - чтобы было не больно читать

Поэтому с джоинами)

А оно контекстуально

В lateral, например

Ещё, например, с LEFT.

спасибо.

Зависит. Если нужно семь разных таблиц поджойнить фиг пойми по чему, то это фиг пойми что иногда лучше в where вынести

а можно еще ON что-то AND что-то ведь)

В географии такое сплошь и рядом :)

"а вот это к этому по лайку, нет, по дистанции к этому, нет, по равенству айди к этому"

а можно еще ON что-то AND что-то ведь)

Ага. А граничные условия тогда в where или в on выносить? ;)

Ага. А граничные условия тогда в where или в on выносить? ;)

это хороший способ не джойнить лишние объемы данных) и все зависит от самого запроса

А еще в where лучше писать условия в том порядке, в котором их стоит проверять :)

ERROR: S client not available

Добрый день! Столкнулись с такой пробемой: Недавно переехали на PostgreSQL на Linux версия - PostgreSQL 9.2.18 on x86_64-redhat-linux-gnu, compiled by gcc (GCC) 4.8.5 20150 623 (Red Hat 4.8.5-11), 64-bit И при выполнении бекапа pg_dump съедает всю память и отваливается с ошибкой out of memory Происходит на шаге: pg_dump: saving database definition Killed Особенности БД - очень много blob. Характеристики сервера - 16Gb памяти. Размер БД ~280Gb На старой машине под Windows бекап все-таки выполнялся, но за полтора дня. Посоветуйте с какими вообще настройками можно поиграться чтобы pg_dump отработал? настройки postgresql.conf я так понимаю для этого не сильно подходят, а параметров запуска pg_dump в общем-то не очень и много ...

Вангую я, что винда использовала своп, однако. Что вывод free говорит?

Вангую я, что винда использовала своп, однако. Что вывод free говорит?

total used free shared buff/cache available Mem: 16264536 363864 184716 2172748 15715956 13354736 Swap: 1678332 58624 1619708

активно начинает есть во время бекапа

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

free - без ключей?

free - без ключей?

да

в момент кила pg_dump сьедает вообще всю свободную память

1,6 гига своп. Думаю я, что это мало. А какой самый большой размер блоба?

Ну а навскидку рисуется следующий костыль: дампится схема (ключик -s) БД с последующим разделением на создание таблиц и создание индексов, а поотом уже данные потаблично, циклом по списку таблиц, с ключиком -a (только данные). Но это совсем лютый костыль. С другой стороны добавлять своп. Сколько его надо - непонятно, а автоматически добавлять, я не слыхал про такое в *нихах вообще.

http://www.hecticgeek.com/2012/01/automatic-virtual-swap-space-creator-ubuntu-linux/

Ну а навскидку рисуется следующий костыль: дампится схема (ключик -s) БД с последующим разделением на создание таблиц и создание индексов, а поотом уже данные потаблично, циклом по списку таблиц, с ключиком -a (только данные). Но это совсем лютый костыль. С другой стороны добавлять своп. Сколько его надо - непонятно, а автоматически добавлять, я не слыхал про такое в *нихах вообще.

вот этого как раз хотелось бы и избежать

Добрый день! Столкнулись с такой пробемой: Недавно переехали на PostgreSQL на Linux версия - PostgreSQL 9.2.18 on x86_64-redhat-linux-gnu, compiled by gcc (GCC) 4.8.5 20150 623 (Red Hat 4.8.5-11), 64-bit И при выполнении бекапа pg_dump съедает всю память и отваливается с ошибкой out of memory Происходит на шаге: pg_dump: saving database definition Killed Особенности БД - очень много blob. Характеристики сервера - 16Gb памяти. Размер БД ~280Gb На старой машине под Windows бекап все-таки выполнялся, но за полтора дня. Посоветуйте с какими вообще настройками можно поиграться чтобы pg_dump отработал? настройки postgresql.conf я так понимаю для этого не сильно подходят, а параметров запуска pg_dump в общем-то не очень и много ...

Если вы используете pg_dump только для backup, то его не надо использовать, тем более с такой большой базой

@Komzpa век жЫви, век учись! Дураком помрёшь. :)

очень простая штука, если думаешь, что чего-то не существуешь, это надо набрать в гугле

Если вы используете pg_dump только для backup, то его не надо использовать, тем более с такой большой базой

хм а какие best practics тогда? все-таки с фулл бекапом спится спокойнее )

фулл бекап - это pg_basebackup

хм а какие best practics тогда? все-таки с фулл бекапом спится спокойнее )

full backup - это basebackup. pg_dump это не та база, которая у вас в PGDATA

full backup - это basebackup. pg_dump это не та база, которая у вас в PGDATA

Это не та база которую вы ищите ))

full backup - это basebackup. pg_dump это не та база, которая у вас в PGDATA

pg_basebackup - это бекап всего кластера, а не одной базы правильно?

хм а какие best practics тогда? все-таки с фулл бекапом спится спокойнее )

Попробуйте barman, pg_probackup, pgbackrest

мда а из коробки все малофункциональное? (((

pg_basebackup - это бекап всего кластера, а не одной базы правильно?

Да, но например, решение pgbackrest, позволяет из basebackup вытащить только одну базу, что очень полезно для восстановления только одной базы и как следствие для разворачивания из prod (в котором много бд) в dev для разработчиков (им нужна только одна ведь бд)

К тому же ваш PGDATA размером в >300G восстановится из basebackup (pgbackrest с опцией —delta) за считанные минуты, вместо over 12 часов pg_restore

К тому же ваш PGDATA размером в >300G восстановится из basebackup (pgbackrest с опцией —delta) за считанные минуты, вместо over 12 часов pg_restore

А почему такая скорость?

Хочу техническую сторону понять

Он снапшот базы делает?

Он получает только измененные данные

Он получает только измененные данные

Ааа. То есть первичное восстановление будет всеравно долгим?

Да, конечно, но скорость будет схожа с простым копированием 300G