@pgsql

Страница 789 из 1062
Глеб
03.05.2018
12:01:23
можешь полайкать мой ответ на stackoverflow
Специально зарегистрировался, но голос не учелся. Эх.

Amir
03.05.2018
14:08:14
всем привет есть ли аналог pg_control_checkpoint()

на 9,5

?

Google
Amir
03.05.2018
14:08:42
или как можно узнать время последнего чекпоинта на 9,5 версии

Evgeniy
03.05.2018
14:10:48
из sql?

Amir
03.05.2018
14:12:03
любые методы)

psql командная строка centos

о точно в логах)

Sergey
03.05.2018
14:20:40
Evgeniy
03.05.2018
14:32:09
можно еще спрашивать каждую секунду pg_stat_bgwriter и смотреть как увеличивается каунтер чекпоинтов

всё для людей же

Amir
03.05.2018
14:33:30
В WAL-логах
это не логи postgres?

Sergey
03.05.2018
14:35:06
это не логи postgres?
Логи, Postgres, но не человекочитаемые www.postgresql.org/docs/current/static/wal-intro.html

Amir
03.05.2018
14:40:27
а в psql есть запрос для 9.5 версии?

*sm1Ly
03.05.2018
15:13:34
товарищи, обьясните глупому что читать. есть тут у меня создание view. в нем select. и там идет к примеру такое: CASE WHEN ((a.dataflow)::text = 'Ebs'::text) THEN 'ebs'::text ELSE 'moex'::text END AS market вот как этот a. появляется?

куда почитать, какую доку

Google
Александр
03.05.2018
15:16:33
Sergey
03.05.2018
15:17:09
select a.name as boss, a2.name as hren_sobachij from personal a, personal a2 where a.emploer_id = a2.boss_id;

Артур
03.05.2018
15:55:49
Возможно ли вложенное наследование несколько раз

Когда таблица a является родителем таблицы b, а она в свою очередь является родителем c

Evgeniy
03.05.2018
15:56:34
возможно

Dmitrii
03.05.2018
15:57:18
А к RETURNING можно еще прилепить дополнительное поле которое не относилось к таблице в которую я что-то вставлял?

У меня INSERT ... FROM SELECT но SELECT сгенерирован через generate_series()

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

Артур
03.05.2018
15:59:09
Evgeniy
03.05.2018
16:01:17
Мне бы вот как то и строку и тот порядковый номер получить.
ретурнинг видит всё что видел инсерт в той строке, сделай returning * и посмотри

Dmitrii
03.05.2018
16:01:59
ретурнинг видит всё что видел инсерт в той строке, сделай returning * и посмотри
Я вот запутался, как мне заселектить на поле больше, но чтобы оно в INSERT не попыталось уйти?

Evgeniy
03.05.2018
16:02:09
а, никак

Dmitrii
03.05.2018
16:02:19
Вот значит никак полуается

Evgeniy
03.05.2018
16:02:27
ну, через ретурнинг никак

через with может

Dmitrii
03.05.2018
16:03:45
О

Хорошая идея, спасибо ) У меня там и так WITH уже был, о втором что-то не подумал

Google
S
03.05.2018
16:08:35
returning это тоже самое что select

create table foo(id int); insert into foo values (1) returning *, 'bar' as f1, 'baz' as f2; id | f1 | f2 ----+-----+----- 1 | bar | baz

Dmitrii
03.05.2018
17:42:50
А если я на вставку отправил 55 миллионов строк, есть какая-то возможность посмотреть сколько в транзакции уже вставилось (записалось на диск?)

Evgeniy
03.05.2018
17:44:07
нет

только косвенно и ненадежно

Dmitrii
03.05.2018
17:44:52
А во, закончило )

10 миллионов ставлялось за 2 минуты, а 55 вставилось за 18

Вот и начал волноваться.

Alexey
03.05.2018
19:21:38
Доброй ночи, а можно ли одну базу постгреса сделать мультитенант? Например есть табличка с миллионом пользователей, котопая соединена разными связами с другими табличками. И чтоб запросы исполнялись только по своим записям ну или ошибка что недостаточно прав потому что пользователь в запросе не указан. Пытаюсь решать проблему мультитенантов

Yaroslav
03.05.2018
19:30:33
Доброй ночи, а можно ли одну базу постгреса сделать мультитенант? Например есть табличка с миллионом пользователей, котопая соединена разными связами с другими табличками. И чтоб запросы исполнялись только по своим записям ну или ошибка что недостаточно прав потому что пользователь в запросе не указан. Пытаюсь решать проблему мультитенантов
Да тут много решений может быть... Например "кросс-пользовательские" запросы нужны? Если да, то скорее всего подойдёт RLS. А, например, если пользователей много, но их данные независимы, можно шардировать... Короче, зависит от конкретных требований.

Evgeniy
03.05.2018
19:35:10
права на схемы

права на таблицы

по тенантам проще просто базы отдельные делать

тупо просто безопасно

отселять удобно

капасити, хуемое

Google
Alexey
03.05.2018
19:38:44
Это тоже вариант, но тяжелый, если есть куча мелких кастомеров то баз на всех не наделаешься

Yaroslav
03.05.2018
19:41:45
Ок посмотрю RLS, а что еще можно посмотреть?
Так что вам нужно-то? Вариантов-то много, но большинство из них должны именно вам не подойти. ;)

Evgeniy
03.05.2018
19:57:18
Это тоже вариант, но тяжелый, если есть куча мелких кастомеров то баз на всех не наделаешься
6 мегабайт на каждого да, плюс юзеры но даже говнохостинги в нулевых давали по три базы!

Voldemar
04.05.2018
03:37:45
https://lwn.net/Articles/752063/

я не понял только, помогают ли от этой напасти чексуммы?

Dmitry
04.05.2018
05:57:09
я не понял только, помогают ли от этой напасти чексуммы?
да, но к сожалению: 1. чексумм на clog помоему до сих пор нет 2. не спасет от усеченного файла

Grigory
04.05.2018
06:37:02
да, но к сожалению: 1. чексумм на clog помоему до сих пор нет 2. не спасет от усеченного файла
По идее, если страница целиком не доехала, то чексуммы не помогут. Будет старая версия страницы с корректной чексуммой

Alexey
04.05.2018
07:25:10
нет, чексуммы тут не спасут. это вообще про другое

Darafei
04.05.2018
07:25:49
только блокчейн :(

Alexey
04.05.2018
07:33:15
но интересный факт, который я как-то раньше не осознавал: в постгресе все процессы вынуждены открывать все нужные файлы заново, создавая новые файловые дескрипторы (ну да, а как ещё). innodb разделяет файловые дескрипторы между всеми потоками, не нужно создавать их копии

Evgeniy
04.05.2018
07:33:16
лайк за блокчейн

Alexey
04.05.2018
07:33:34
и у этого наверняка есть интересные следствия...

Darafei
04.05.2018
07:38:52
а ещё никто не предлагал чексуммы хранить отдельно и подальше от самих блоков?

Konstantin
04.05.2018
07:39:18
и у этого наверняка есть интересные следствия...
Это скорее плюс, чем минус. По крайней мере, когда я переписывал Посгрес на потоки, я об эти грабли здорово приложился. В Посгресе есть пул открытых дескрипторов (чтобы не вылететь за системное граничение по числу открытых дескрипторов в одном процессе). Я сначала пытался сделать общий кэш дескрипторов для всех потоков, но синхронизация доступа к этому кэшу сразу же стала узким местом. Пришлось от этого отказаться и оставить локальные кэши для каждого потока, но размер каждого кэша уменьшить пропорционально числу потоков (что конечно плохо).

Amir
04.05.2018
07:46:08
о каких то высоких материях говорите, дайте плиз ссылку на познание силы

Amir
04.05.2018
07:49:08
да можно и туда

Konstantin
04.05.2018
07:52:42
это вопрос оптимизации доступа к пулу. в innodb была проделана работа по переводу fil_system на lock-free/wait-free структуры
Ес-но. У меня не было времени и желания в это залезать. К тому же, в Посгресе до сих пор не отказались от использования lseek-ов, хотя всё таки грозятся в 12-ой версии перейти на pread/pwrite.

Google
Alexey
04.05.2018
07:55:04
Ес-но. У меня не было времени и желания в это залезать. К тому же, в Посгресе до сих пор не отказались от использования lseek-ов, хотя всё таки грозятся в 12-ой версии перейти на pread/pwrite.
хорошо хоть в 12-й грозятся. кстати в mysql 8 пользовательские (foreground) потоки вообще не трогают файлы. всё, включая запись в redo log делается в background потоках. поэтому конкурентность доступа к общему пулу дескрипторов невысокая

Venera
04.05.2018
07:56:33
Привет всем! Есть необходимость сохранить utc смещение( типа '+hh:mm', '-hh:mm'). Не подскажете в каком типе лучше это хранить?

Сергей
04.05.2018
07:59:16
Venera
04.05.2018
08:01:07
спасибо, да нужно без даты, сохраню в int

Сергей
04.05.2018
08:02:38
https://www.postgresql.org/docs/9.1/static/datatype-datetime.html вообще вот дока. сам я смещения не хранил, но в доке тут упоминается именно interval, я бы на вашем месте доверился доке и взял его

Evgeniy
04.05.2018
08:04:34
у офсета нет начала и конца, куда тут интервал

Yaroslav
04.05.2018
08:26:54
Привет всем! Есть необходимость сохранить utc смещение( типа '+hh:mm', '-hh:mm'). Не подскажете в каком типе лучше это хранить?
Зависит от того, зачем нужно (почему фиксированное смещение?). Может, и в виде названия timezone..

да можно и туда
Раз: https://www.postgresql.org/message-id/CAMsr%2BYHh%2B5Oq4xziwwoEfhoTZgr07vdGG%2Bhu%3D1adXx59aTeaoQ%40mail.gmail.com И два: https://www.postgresql.org/message-id/20180427222842.in2e4mibx45zdth5@alap3.anarazel.de

нет, чексуммы тут не спасут. это вообще про другое
А (просто из интереса), в сообществе MySQL смотрели на эту проблему? А то тут Robert Haas заглядывал в код MariaDB: https://www.postgresql.org/message-id/CA%2BTgmoapNxRAvfnOFD4FPM10wT90gjfgGZhDHW4kn%3DmOEVkuFQ%40mail.gmail.com Он просто не понял или... "добро пожаловать в клуб"? ;)

Yaroslav
04.05.2018
08:40:03
А, ну то есть на старых ядрах у MySQL та же проблема, "поздравляю". ;(

Alexey
04.05.2018
08:40:18
но там нужно понимать, что "площадь проблемы" в innodb сильно меньше, чем в postgresql. потому что относится только 1) к записи в redo log и 2) в случае буферизованного IO в InnoDB, который редко используется. обычно используется direct IO, который к этой проблеме нечувствителен

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

Alexey
04.05.2018
08:42:05
А для data files там что используется?
direct IO, если innodb_flush_method=O_DIRECT. в этом есть много плюсов, поэтому его обычно и используют

Yaroslav
04.05.2018
08:43:05
и да, и нет :) потому что вот это "давайте повторим fsync(), если он вернул ошибку" сделали тоже недавно. то есть оно недолго просуществовало
Так дело-то в том, что в старых ядрах ошибка просто "глотается", т.е., например, одновременно прошёл по "вашему" файлу tar... и он получил эту ошибку, а вы _никогда_ не получите (если я правильно понял). :(

Alexey
04.05.2018
08:43:41
а ещё мне интересна вот эта необъяснимая любовь постгрес-сообщества к mariadb. вот почему Хаас полез первым делом туда, а не в первоисточник (Oracle/MySQL)? не понимаю

Так дело-то в том, что в старых ядрах ошибка просто "глотается", т.е., например, одновременно прошёл по "вашему" файлу tar... и он получил эту ошибку, а вы _никогда_ не получите (если я правильно понял). :(
в форках (Percona Server, MariaDB) есть опция innodb_flush_method=ALL_O_DIRECT, который включает direct IO не только для файлов данных, но и для redo log. т.е. полностью исключает проблему на любых ядрах

но опять же, даже на ванильном mysql с innodb_flush_method=O_DIRECT вероятность словить эту проблему в innodb меньше, чем в постгресе

Страница 789 из 1062