Доброго времени суток всем! Подскажите пожалуйста, почему pg_dump и pg_dumpall делает только дамп структуры, но не данные, которые находятся в бд?

Доброго времени суток всем! Подскажите пожалуйста, почему pg_dump и pg_dumpall делает только дамп структуры, но не данные, которые находятся в бд?

видимо опции так заставляют

>$SCHEMA_ONLY_QUERY

set work_mem = '32 GB'; требуется ли при этом рестарт пг? 9.6

Нет. Релоад.

А в случае если сделано в сессии не нужно

Разве нельзя просто сделать дамп базы со структурой данных?

>$SCHEMA_ONLY_QUERY

там внутри скорей всего эта ошибка выходит, поскажите, что она означает? pg_dumpall: query failed: ERROR: permission denied for relation pg_authid

А в случае если сделано в сессии не нужно

сессия - это psql например?

сессия - это psql например?

Да

@AntonBychkovski будет жить. Поприветствуем!

там внутри скорей всего эта ошибка выходит, поскажите, что она означает? pg_dumpall: query failed: ERROR: permission denied for relation pg_authid

А где Вы взяли это вот? И с какой целью хотите использовать? > permission denied for relation pg_authid Скорее всего, не из-под superuser снимаете.

А где Вы взяли это вот? И с какой целью хотите использовать? > permission denied for relation pg_authid Скорее всего, не из-под superuser снимаете.

Да уже решил, спасибо. Сам команду написал. Лучше чем скрипт отработала. Оказывается нужно schema выбрать) Незнал что здесь в базе есть еще куча под названием schema)

Привык к мускулу

Да уже решил, спасибо. Сам команду написал. Лучше чем скрипт отработала. Оказывается нужно schema выбрать) Незнал что здесь в базе есть еще куча под названием schema)

Хмм... так зачем Вам эта штука вообще, всё же?

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

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

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

запрос самый простой(: SELECT ST_AsBinary("way") AS geom,"name","name:en", place AS "type", z_order, population FROM planet_osm_point WHERE place in ('country', 'state', 'city', 'town', 'village', 'hamlet', 'suburb', 'neighbourhood', 'locality') and "way" && ST_SetSRID('BOX3D(624935 5011821, 1889525 6266615)'::box3d, 3857) ORDER BY population DESC NULLS LAST;

Ну и? C виду, всё нормально, нет?

Ну и? C виду, всё нормально, нет?

Который из трёх планов?

Который из трёх планов?

Все.

13 секунд точно не нормально ящитаю

13 секунд точно не нормально ящитаю

Эээ... а причём тут это? Row estimations соответствуют, какие у Вас cost-ы — Вам виднее, время выполнения на 100% кэшированных данных, вообще говоря, не имеет отношения ни к чему.

13 секунд точно не нормально ящитаю

Вот только на это можно посмотреть, наверное: > Rows Removed by Filter: 179633 Добавить это поле в индекс, может быть (с помощью btree_gist)? Или Вы видите ещё какие проблемы?

о жесть там какая...

Ни...чего себе! Я только что прочитал продолжение (а как невинно всё начиналось). :(

Всем привет! помогите плз сообразить, как мне добавить два CHECK constraint на то, что p1 и p2 = 0 если g = 0; и что p1 и p2 != 0 если g != 0? Таблица такая: CREATE TABLE table1 ( id serial PRIMARY KEY, p1 bigint, p2 bigint, g bigint );

Вот так будет нормально? CREATE TABLE table1 ( id serial PRIMARY KEY, p1 bigint , p2 bigint, g bigint CHECK((g=0 AND p1=0 AND p2=0)OR(g<>0 AND p1<>0 AND p2<>0)) );

Вот так будет нормально? CREATE TABLE table1 ( id serial PRIMARY KEY, p1 bigint , p2 bigint, g bigint CHECK((g=0 AND p1=0 AND p2=0)OR(g<>0 AND p1<>0 AND p2<>0)) );

если g != 0, то p1 и p2 тоже не должны быть равны 0?

если g != 0, то p1 и p2 тоже не должны быть равны 0?

да. Если g=0, то p1 и p2 должны быть равны нулю, а если g!=0, то p1 и p2 не должны быть равны нулю.

То, что я написал - работает, но есть подозрение, что есть более правильный способ решения задачи.

То, что я написал - работает, но есть подозрение, что есть более правильный способ решения задачи.

Да главное, чтобы понятно было, IMHO. А то можно и докатиться до: WITH v(v) AS ( VALUES (0), (1) ), vals AS ( SELECT p1.v AS p1, p2.v AS p2, g.v AS g FROM v AS p1, v AS p2, v AS g ) SELECT *, (g=0 AND p1=0 AND p2=0) OR (g<>0 AND p1<>0 AND p2<>0) AS ok, (p1=0) = (p2=0) AND (p2=0) = (g=0) AS bad, num_nulls(NULLIF(g, 0), NULLIF(p1, 0), NULLIF(p2, 0)) IN (0, 3) AS crazy FROM vals ;)

Да главное, чтобы понятно было, IMHO. А то можно и докатиться до: WITH v(v) AS ( VALUES (0), (1) ), vals AS ( SELECT p1.v AS p1, p2.v AS p2, g.v AS g FROM v AS p1, v AS p2, v AS g ) SELECT *, (g=0 AND p1=0 AND p2=0) OR (g<>0 AND p1<>0 AND p2<>0) AS ok, (p1=0) = (p2=0) AND (p2=0) = (g=0) AS bad, num_nulls(NULLIF(g, 0), NULLIF(p1, 0), NULLIF(p2, 0)) IN (0, 3) AS crazy FROM vals ;)

Адъ

Anonymous будет жить. Поприветствуем!

Vladislav Aleksandrov будет жить. Поприветствуем!

Вот только на это можно посмотреть, наверное: > Rows Removed by Filter: 179633 Добавить это поле в индекс, может быть (с помощью btree_gist)? Или Вы видите ещё какие проблемы?

-> Bitmap Index Scan on idx_points_place ?

https://explain.depesz.com/s/NNVh это уже терпимо для этого железа

https://explain.depesz.com/s/NNVh это уже терпимо для этого железа

Хмм... я так и не понял, почему Вы уверены, что индекс действительно лучше (я уже писал про cost-ы.) Кстати, железо у Вас какое-то... не очень, похоже (0.7 сек на сортировку всего-то 88744 rows не впечатляет).

Хмм... я так и не понял, почему Вы уверены, что индекс действительно лучше (я уже писал про cost-ы.) Кстати, железо у Вас какое-то... не очень, похоже (0.7 сек на сортировку всего-то 88744 rows не впечатляет).

Scaleway VC1L по 9.99 парижских евро в костах извините не разбираюсь ) секскан исчез — я рад!

Scaleway VC1L по 9.99 парижских евро в костах извините не разбираюсь ) секскан исчез — я рад!

> в костах извините не разбираюсь А зря. ;) > секскан исчез — я рад! Вот мне и интересно — чему? При реальной нагрузке этот план может быть в самом деле медленее, чем seqscan. Как я уже писал, по одному тесту на кешированных данных нельзя делать никаких выводов, в общем случае. Впрочем, если у Вас в самом деле 100% базы (почти) всегда в RAM, то можно, но это значит, что random_page_cost / cpu_tuple_cost у Вас настроены неверно.

этот "сервер" не для реальной нагрузки. база 65Гб, озу 8, настройки наверняка не оптимальны. но точить топор некогда, надо рубить ))

этот "сервер" не для реальной нагрузки. база 65Гб, озу 8, настройки наверняка не оптимальны. но точить топор некогда, надо рубить ))

Тогда мне вообще непонятно, зачем Вы вообще что-то оптимизируете, серьёзно. > но точить топор некогда, надо рубить )) Т.е. что Вам надо "рубить"?

Тогда мне вообще непонятно, зачем Вы вообще что-то оптимизируете, серьёзно. > но точить топор некогда, надо рубить )) Т.е. что Вам надо "рубить"?

как бы мне комфортней не ждать лишние 10 секунд, потому и озаботился. лог условно долгих (больше 3 сек) запросов ведется, когда уж сильно анноить начинает я туда заглядываю и начинаю разбираться с самым слабым звеном (это не я))

как бы мне комфортней не ждать лишние 10 секунд, потому и озаботился. лог условно долгих (больше 3 сек) запросов ведется, когда уж сильно анноить начинает я туда заглядываю и начинаю разбираться с самым слабым звеном (это не я))

Так Вы один с этой базой работаете? И примерно одинаковые запросы друг за другом выдаёте, наверное?

"рублю" стиль для тайл-карты, постоянно приходится чистить кеш тайлов и рестартовать апач (долго объяснять) да, там я один сижу. запросы действительно примерно одинаковые: для каждого слоя геоданных свой запрос, меняется по сути только ббокс.

> в костах извините не разбираюсь А зря. ;) > секскан исчез — я рад! Вот мне и интересно — чему? При реальной нагрузке этот план может быть в самом деле медленее, чем seqscan. Как я уже писал, по одному тесту на кешированных данных нельзя делать никаких выводов, в общем случае. Впрочем, если у Вас в самом деле 100% базы (почти) всегда в RAM, то можно, но это значит, что random_page_cost / cpu_tuple_cost у Вас настроены неверно.

osmlatest=> show random_page_cost; random_page_cost ------------------ 1.05 (1 строка) osmlatest=> show cpu_tuple_cost; cpu_tuple_cost ---------------- 0.01 (1 строка)

osmlatest=> show random_page_cost; random_page_cost ------------------ 1.05 (1 строка) osmlatest=> show cpu_tuple_cost; cpu_tuple_cost ---------------- 0.01 (1 строка)

Да, тогда random_page_cost подходящий, скорее всего. Да можно и cpu_tuple_cost попробовать 0.1 (или даже 0.2), наверное.

Да, тогда random_page_cost подходящий, скорее всего. Да можно и cpu_tuple_cost попробовать 0.1 (или даже 0.2), наверное.

в 10 или даже 20 раз!? пойду ка почитаю тогда

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

т.е. cpu_tuple_cost скажет, что стоимость выросла в 10 раз. и что тогда?

в 10 или даже 20 раз!? пойду ка почитаю тогда

Да, а почему бы нет? Если всё закешировано, значит отностительная стоимость (к seq_page_cost) обработки в памяти, наоборот, становится выше. А такие значения я тоже взял не с потолка — многие, у кого RAM-only workloads (ну или близко к тому) говорят, что это +-адекватно.

Да, а почему бы нет? Если всё закешировано, значит отностительная стоимость (к seq_page_cost) обработки в памяти, наоборот, становится выше. А такие значения я тоже взял не с потолка — многие, у кого RAM-only workloads (ну или близко к тому) говорят, что это +-адекватно.

но ведь у меня явно не так. если б я с одним городом развлекался, то да (даже Челябинская область наверно). но когда речь про Японию или Италию, то тут и 32 гигов будет маловато

но на 32 гига я не зарабатываю этой работкой )

вот бы кто визуализировал взаимозависимость констант стоимости планировщика *_cost

т.е. cpu_tuple_cost скажет, что стоимость выросла в 10 раз. и что тогда?

Т.е. соответственно планы, которые состоят в обработке/фильтрации (выкидывании) большого количества tuples, "штрафуются". Т.е. по-умолчанию для планировщика использование индекса — это "сразу мало, но дорого выбрать", а seqscan — "много, но дёшево выбрать, но быстро отбросить." Увеличение cpu_tuple_cost намекает планировщику, что отбрасывать — медленно. ;)

18.7.2. Константы стоимости для планировщика Переменные стоимости, описанные в данном разделе, задаются по произвольной шкале. Значение имеют только их отношения, поэтому умножение или деление всех переменных на один коэффициент никак не повлияет на выбор планировщика. По умолчанию эти переменные определяются относительно стоимости чтения последовательной страницы: то есть, переменную seq_page_cost удобно задать равной 1.0, а все другие переменные стоимости определить относительно неё. Но при желании можно использовать и другую шкалу, например, выразить в миллисекундах фактическое время выполнения запросов на конкретной машине.

но ведь у меня явно не так. если б я с одним городом развлекался, то да (даже Челябинская область наверно). но когда речь про Японию или Италию, то тут и 32 гигов будет маловато

Вам виднее. Я думал, что Вы занимаетесь сначала одним набором данных (т.е. он весь +- кешируется), затем другим, и т.п. Т.е. в момент перехода с одного набора на другой, конечно, стоимости будут неадекватны реальности... ну и что? ;)

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

> в общем алгоритм нащупывания костов для конкретной задачи на конкретном железе видится мне не очень сложным. Да если бы. Это же не от железа зависит, в основном. Как пример, если у Вас размер базы << RAM, правильное значение random_page_cost — это 1.0, и вообще неважно, какие у Вас диски! > сначала с разными крайними значениями получаем планы трех (например) вариантов, и уже дело техники их сравнить и прийти к определенным выводам. И тут же "влезают" shared_buffers и кэш файловой системы, и полностью искажают все расчёты. :(

> в общем алгоритм нащупывания костов для конкретной задачи на конкретном железе видится мне не очень сложным. Да если бы. Это же не от железа зависит, в основном. Как пример, если у Вас размер базы << RAM, правильное значение random_page_cost — это 1.0, и вообще неважно, какие у Вас диски! > сначала с разными крайними значениями получаем планы трех (например) вариантов, и уже дело техники их сравнить и прийти к определенным выводам. И тут же "влезают" shared_buffers и кэш файловой системы, и полностью искажают все расчёты. :(

Это ж чинит effectice_cache_size?

Это ж чинит effectice_cache_size?

Ну, вообще-то, чинит он немного, нет?

Ну в случае постгиса вообще беда в том, что в оценку никак не включается О() самой функции

Ну в случае постгиса вообще беда в том, что в оценку никак не включается О() самой функции

А я вообще на postgis-овские estimators никогда не смотрел, кажется... Но вообще да, по идее, это может быть существенной проблемой... если есть альтернативный путь выполнения запроса. Там есть?

Да

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

Да

Хмм... и как разработчики postgis это решают?

@Electronik777 будет жить. Поприветствуем!

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

В смысле будет ли скопировано содержимое таблицы, но без указанной колонки.

В смысле будет ли скопировано содержимое таблицы, но без указанной колонки.

vacuum full наше всё )

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

Нет

Нет

Спасибо

всем привет. у меня в таблице такая структура user | tag ————— user1 : tag1 user1: tag2 user2: tag1 мне надо делать query так, чтобы я получил всех юзеров у которых есть и tag1 и tag2. по сути в данном примере только user1. как можно это делать?

всем привет. у меня в таблице такая структура user | tag ————— user1 : tag1 user1: tag2 user2: tag1 мне надо делать query так, чтобы я получил всех юзеров у которых есть и tag1 и tag2. по сути в данном примере только user1. как можно это делать?

подзапросом в in

подзапросом в in

IN вроде дает если есть хоть один из этих. то есть у user2 дает. а мне надо именно только User1, Ибо только у него и tag1 и tag2

хм, а задачка веселее чем кажется на первый взгляд

всем привет. у меня в таблице такая структура user | tag ————— user1 : tag1 user1: tag2 user2: tag1 мне надо делать query так, чтобы я получил всех юзеров у которых есть и tag1 и tag2. по сути в данном примере только user1. как можно это делать?

Example 1 select t.user from t as t1, t as t2 where t1.user = t2.user and t1.tag = 'tag1' and t2.tag = 'tag2' Example 2 select user from ( select user, array_agg(tag) as tags from t group by user ) as tmp where 'tag1' in tags and 'tag2' in tags

спасибо, щас попробую оба

Example 1 select t.user from t as t1, t as t2 where t1.user = t2.user and t1.tag = 'tag1' and t2.tag = 'tag2' Example 2 select user from ( select user, array_agg(tag) as tags from t group by user ) as tmp where 'tag1' in tags and 'tag2' in tags

Когда появится тег3 запрос переписывать?..)

Когда появится тег3 запрос переписывать?..)

Искусственный интелект хочешь?)

Или то, что читает твои мысли

Искусственный интелект хочешь?)

Универсальности. Что-то типа предварительной выборки в массив всех уникальных тегов

Но может быть я неправильно понял что автор имел в виду))

Example 1 select t.user from t as t1, t as t2 where t1.user = t2.user and t1.tag = 'tag1' and t2.tag = 'tag2' Example 2 select user from ( select user, array_agg(tag) as tags from t group by user ) as tmp where 'tag1' in tags and 'tag2' in tags

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