можешь полайкать мой ответ на stackoverflow

Специально зарегистрировался, но голос не учелся. Эх.

всем привет есть ли аналог pg_control_checkpoint()

на 9,5

?

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

из sql?

любые методы)

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

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

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

В WAL-логах

можно еще спрашивать каждую секунду pg_stat_bgwriter и смотреть как увеличивается каунтер чекпоинтов

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

В WAL-логах

это не логи postgres?

это не логи postgres?

Логи, Postgres, но не человекочитаемые www.postgresql.org/docs/current/static/wal-intro.html

а в psql есть запрос для 9.5 версии?

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

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

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

Это alias для допустим таблицы.

Если надо например таблицу саму с собой сджойнить ожно использовать

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

после оператора FROM у тебя будет скорей всего имя таблицы и далее идет как раз алиас например : select a.id from table1 a

select a.name as boss, a2.name as hren_sobachij from personal a, personal a2 where a.emploer_id = a2.boss_id;

после оператора FROM у тебя будет скорей всего имя таблицы и далее идет как раз алиас например : select a.id from table1 a

вооооо! спасибо большое, это помогло.

Возможно ли вложенное наследование несколько раз

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

возможно

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

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

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

возможно

спс

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

ретурнинг видит всё что видел инсерт в той строке, сделай returning * и посмотри

ретурнинг видит всё что видел инсерт в той строке, сделай returning * и посмотри

Я вот запутался, как мне заселектить на поле больше, но чтобы оно в INSERT не попыталось уйти?

а, никак

Вот значит никак полуается

ну, через ретурнинг никак

через with может

О

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

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

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

нет

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

А во, закончило )

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

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

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

Смотря как вы отправили

Если через копи то можно в пайп вставить pv

Типа того

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

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

Да тут много решений может быть... Например "кросс-пользовательские" запросы нужны? Если да, то скорее всего подойдёт RLS. А, например, если пользователей много, но их данные независимы, можно шардировать... Короче, зависит от конкретных требований.

Да тут много решений может быть... Например "кросс-пользовательские" запросы нужны? Если да, то скорее всего подойдёт RLS. А, например, если пользователей много, но их данные независимы, можно шардировать... Короче, зависит от конкретных требований.

Ок посмотрю RLS, а что еще можно посмотреть?

права на схемы

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

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

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

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

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

Это тоже вариант, но тяжелый, если есть куча мелких кастомеров то баз на всех не наделаешься

Ок посмотрю RLS, а что еще можно посмотреть?

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

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

Не знаю пока :) буду думать

Это тоже вариант, но тяжелый, если есть куча мелких кастомеров то баз на всех не наделаешься

6 мегабайт на каждого да, плюс юзеры но даже говнохостинги в нулевых давали по три базы!

https://lwn.net/Articles/752063/

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

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

да, но к сожалению: 1. чексумм на clog помоему до сих пор нет 2. не спасет от усеченного файла

да, но к сожалению: 1. чексумм на clog помоему до сих пор нет 2. не спасет от усеченного файла

По идее, если страница целиком не доехала, то чексуммы не помогут. Будет старая версия страницы с корректной чексуммой

нет, чексуммы тут не спасут. это вообще про другое

только блокчейн :(

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

лайк за блокчейн

и у этого наверняка есть интересные следствия...

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

и у этого наверняка есть интересные следствия...

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

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

это вопрос оптимизации доступа к пулу. в innodb была проделана работа по переводу fil_system на lock-free/wait-free структуры

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

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

-hackers?

да можно и туда

это вопрос оптимизации доступа к пулу. в innodb была проделана работа по переводу fil_system на lock-free/wait-free структуры

Ес-но. У меня не было времени и желания в это залезать. К тому же, в Посгресе до сих пор не отказались от использования lseek-ов, хотя всё таки грозятся в 12-ой версии перейти на pread/pwrite.

Ес-но. У меня не было времени и желания в это залезать. К тому же, в Посгресе до сих пор не отказались от использования lseek-ов, хотя всё таки грозятся в 12-ой версии перейти на pread/pwrite.

хорошо хоть в 12-й грозятся. кстати в mysql 8 пользовательские (foreground) потоки вообще не трогают файлы. всё, включая запись в redo log делается в background потоках. поэтому конкурентность доступа к общему пулу дескрипторов невысокая

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

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

если смещение без самой даты, то в int поле в минутах, либо в interval

спасибо, да нужно без даты, сохраню в int

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

у офсета нет начала и конца, куда тут интервал

Привет всем! Есть необходимость сохранить 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 Он просто не понял или... "добро пожаловать в клуб"? ;)

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

смотрели, да. по моей наводке: https://bugs.mysql.com/bug.php?id=90296

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

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

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

и да, и нет :) потому что вот это "давайте повторим fsync(), если он вернул ошибку" сделали тоже недавно. то есть оно недолго просуществовало

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

А для data files там что используется?

А для data files там что используется?

direct IO, если innodb_flush_method=O_DIRECT. в этом есть много плюсов, поэтому его обычно и используют

и да, и нет :) потому что вот это "давайте повторим fsync(), если он вернул ошибку" сделали тоже недавно. то есть оно недолго просуществовало

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

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

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

в форках (Percona Server, MariaDB) есть опция innodb_flush_method=ALL_O_DIRECT, который включает direct IO не только для файлов данных, но и для redo log. т.е. полностью исключает проблему на любых ядрах

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