А можно подробности? Чтение из памяти же тоже разным бывает. Сравнивалось чтение из файла в темпфс и замапленного в память?

Я же сказал - за давностью лет не помню. Но вот отпечаток остался, да.

А в plpython существует возможность как-то дополнить глобальные переменные ? или пользовать те же SD / GD ? кто нибудь сталиквался с такой необходимостью ?

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

Разница в производительности данных в буфере ПГ и данных на той же tmpfs раза в 2,5 всего

Вот ещё один "эксперт" по срачу:) Этим Миша занимался весь год или больше в ПгПро. Остутствие знаний компенсируется желанием влезть в любую дискуссию и и там оставить свою кучку. Поэтому, прошу прощения, но на Мишины впросы и реплики я отвечать не буду.

Самое забавное именно в этом заявлении то, что именно ты мне объяснял работу репликации в постгресе, которую я озвучил выше. Вот такие вот пироги.

Ну тогда я тебя готов выслушать почему у меня cp в несколько потоков в tmpfs дает 38 ГБ/с в tmpfs. Не уверен что чото другое даст скорость в 3800 ГБ/с

Ну рискну предположить, что для темпфс используются дополнительные уровни абстракции - поэтому медленнее. Но на практике не знаю.

Огонь дела. Читаю вот, жду за что зацепится. Пока только за поиски %)

молодец! не снижать накал борьбы!

молодец! не снижать накал борьбы!

Всегда!

Ну тогда я тебя готов выслушать почему у меня cp в несколько потоков в tmpfs дает 38 ГБ/с в tmpfs. Не уверен что чото другое даст скорость в 3800 ГБ/с

Т.е. то, что мне показали только чтение, ты пропустил мимо глаз. так держать!

У тебя и мультимастер не ломается.

Почитал по диагонали дизайн в innodb. В innodb дизайн действительно сложный и многослойный. Наверняка, в определенных ситуациях он лучше. Дизайн в постгресс-про - это те самые 20% усилий, что дают 80% профита. И мне сложно назвать такой подход "детским лепетом". Скорее, здоровый консервативный подход: снять сливки, посмотреть на результат.

слушайте, может вы там в ПгПро устроите internal knowledge sharing? там вот два человека жаждут подробностей, а у вас уже есть. и мне время сэкономите

Салют! пардон за возможно нубский вопрос: есть таблица id | appname | appstatus —--+-------------+---------— 55 | example_WM | APP_START 35 | WM-0000000d | APP_END 40 | WM-0000000f | APP_END 45 | WM-0000000f | APP_END 47 | WM-0000000d | USER_DEF 50 | WM-0000000f | USER_DEF 53 | WM-0000000f | USER_DEF 28 | WM-0000000e | APP_START 46 | WM-0000000d | APP_START 48 | WM-0000000e | APP_START 49 | WM-0000000f | APP_START 51 | WM-00000010 | APP_START 52 | WM-0000000f | APP_START 54 | WM-00000010 | APP_START 30 | WM-0000000e | APP_END 32 | WM-0000000e | APP_END 34 | WM-0000000d | APP_END 37 | WM-00000010 | APP_END 39 | WM-0000000f | APP_END 42 | WM-00000010 | APP_END 44 | WM-0000000f | APP_END 29 | WM-0000000e | HANG 31 | WM-0000000e | HANG 33 | WM-0000000d | HANG 36 | WM-00000010 | HANG 38 | WM-0000000f | HANG 41 | WM-00000010 | HANG 43 | WM-0000000f | HANG Каким запросом можно выбрать все appname, для которых случилось событие APP_START, но больше никаких событий не произошло? Т.е. в этом случае должно вывести только example_WM

Салют! пардон за возможно нубский вопрос: есть таблица id | appname | appstatus —--+-------------+---------— 55 | example_WM | APP_START 35 | WM-0000000d | APP_END 40 | WM-0000000f | APP_END 45 | WM-0000000f | APP_END 47 | WM-0000000d | USER_DEF 50 | WM-0000000f | USER_DEF 53 | WM-0000000f | USER_DEF 28 | WM-0000000e | APP_START 46 | WM-0000000d | APP_START 48 | WM-0000000e | APP_START 49 | WM-0000000f | APP_START 51 | WM-00000010 | APP_START 52 | WM-0000000f | APP_START 54 | WM-00000010 | APP_START 30 | WM-0000000e | APP_END 32 | WM-0000000e | APP_END 34 | WM-0000000d | APP_END 37 | WM-00000010 | APP_END 39 | WM-0000000f | APP_END 42 | WM-00000010 | APP_END 44 | WM-0000000f | APP_END 29 | WM-0000000e | HANG 31 | WM-0000000e | HANG 33 | WM-0000000d | HANG 36 | WM-00000010 | HANG 38 | WM-0000000f | HANG 41 | WM-00000010 | HANG 43 | WM-0000000f | HANG Каким запросом можно выбрать все appname, для которых случилось событие APP_START, но больше никаких событий не произошло? Т.е. в этом случае должно вывести только example_WM

NOT EXISTS, например.

слушайте, может вы там в ПгПро устроите internal knowledge sharing? там вот два человека жаждут подробностей, а у вас уже есть. и мне время сэкономите

К сожалению, я уже не в постресс-про :-( продал себя в торговую компанию.

а, пардон ?

@alexey_kopytov , насколько я понял,@funny_falcon самый близкий к реальной реализации в pgpro человек. Если вы с ним обсудите подробности реализаций в mysql и pgpro - все тут будут рады новым знаниям

@alexey_kopytov , насколько я понял,@funny_falcon самый близкий к реальной реализации в pgpro человек. Если вы с ним обсудите подробности реализаций в mysql и pgpro - все тут будут рады новым знаниям

Самый близкий из этого разговора - @knizhnik .

По теме данного разговора (в части про кэширование и т.п.) я вот прямо не удержусь и вброшу: <Кто-то спрашивает> Is there a good survey/paper/thing to read to get up to speed on cache replacement algorithms? Andres Freund отвечает: I think it's to a significant degree our implementation, rather than purely algorithmic issues. (chiefly among them: bgwriter is useless to damaging; usagecount granularity too low / decays too fast / increases too fast, but can't be increased because overhead scales O(shared_buffers * max_usagecount); undirtying doesn't do write combining) I'd posted a draft bgwriter replacement somewhere which in my experiments did a lot better than the current one despite being simpler. The write combining issue IMO requires that we replace our current hashtable with an ordered tree (which'd also fix the drop table being O(#shared buffers) issue). My experiment suggests that in comparison to the current replacement logic, random replacement does just about the same. It's definitely possible to construct cases where that's not true however.

Мне особенно понравилось "in comparison to the current replacement logic, random replacement does just about the same". ;)

ой, а что, drop table до сих пор O(#shared buffers)?

Я сам не знаю, но ответ от февраля этого года, насколько я помню..

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

Я сам не знаю, но ответ от февраля этого года, насколько я помню..

а можно ссылку? оно почему-то не гуглится

а можно ссылку? оно почему-то не гуглится

И не нагуглится, потому что это из IRC.

печаль

Никита и Константин. Задайте свои вопросы позднее. Не вовремя вы пришли

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

"Нет царских путей к геометрии". Т.е. прочитайте документацию, а если есть конкретные вопросы —- задавайте.

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

https://www.postgresql.org/docs/10/static/functions.html Читай...

NOT EXISTS, например.

спасибо, буду курить

https://www.postgresql.org/docs/10/static/functions.html Читай...

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

Салют! пардон за возможно нубский вопрос: есть таблица id | appname | appstatus —--+-------------+---------— 55 | example_WM | APP_START 35 | WM-0000000d | APP_END 40 | WM-0000000f | APP_END 45 | WM-0000000f | APP_END 47 | WM-0000000d | USER_DEF 50 | WM-0000000f | USER_DEF 53 | WM-0000000f | USER_DEF 28 | WM-0000000e | APP_START 46 | WM-0000000d | APP_START 48 | WM-0000000e | APP_START 49 | WM-0000000f | APP_START 51 | WM-00000010 | APP_START 52 | WM-0000000f | APP_START 54 | WM-00000010 | APP_START 30 | WM-0000000e | APP_END 32 | WM-0000000e | APP_END 34 | WM-0000000d | APP_END 37 | WM-00000010 | APP_END 39 | WM-0000000f | APP_END 42 | WM-00000010 | APP_END 44 | WM-0000000f | APP_END 29 | WM-0000000e | HANG 31 | WM-0000000e | HANG 33 | WM-0000000d | HANG 36 | WM-00000010 | HANG 38 | WM-0000000f | HANG 41 | WM-00000010 | HANG 43 | WM-0000000f | HANG Каким запросом можно выбрать все appname, для которых случилось событие APP_START, но больше никаких событий не произошло? Т.е. в этом случае должно вывести только example_WM

select distinct appname from thetable l where app_status = 'APP_START' and not exists( select 1 from thetable l0 where l0.id = l.id and l0.appstatus <> 'APP_START' )

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

А вы с какой-нибудь RDBMS знакомы? Может, можно будет в сравнении что-то рассказать (если кто-то знаком с той же, что и вы)?

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

Когда изучишь, ты его получишь. Так вообще не понятно, что тебе надо. Учить всё вообще бессмысленно. Обычно тебе надо что-то сделать, ты ищешь фукнцию под это, и её изучаешь. ПОтом используешь.

А вы с какой-нибудь RDBMS знакомы? Может, можно будет в сравнении что-то рассказать (если кто-то знаком с той же, что и вы)?

А бессмысленнО, как раз функциии во всех СУБД разные. Совсем. (кроме стандартных в новых СУБД)

А бессмысленнО, как раз функциии во всех СУБД разные. Совсем. (кроме стандартных в новых СУБД)

Просили "рассказать о особенностях и полезных функциях", так что я так не думаю.

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

ОБЩЕЕ ПРЕДСТАВЛЕНИЕ: Есть функции, каждая либо универсальная (из области SQL), либо обычно привязана к обработке какого-то типа данных. Изучаешь тип данных — изучаешь связанные с ним функции.

А бессмысленнО, как раз функциии во всех СУБД разные. Совсем. (кроме стандартных в новых СУБД)

Я согласен, что изучается все по мере необходимости. Я работаю с Postgresql и все задачи решаю, но не сказать, что приходилось заходить слишком далеко. У postgresql есть свои преимущества и недостатки, какие то особенности, которые могут так сказать навредить, если я их буду использовать. А чтобы не наткнуться на них по незнанию, вот и спросил)

В Postgres есть недостатки ? Ты сейчас серьёзно сказал ?

Я согласен, что изучается все по мере необходимости. Я работаю с Postgresql и все задачи решаю, но не сказать, что приходилось заходить слишком далеко. У postgresql есть свои преимущества и недостатки, какие то особенности, которые могут так сказать навредить, если я их буду использовать. А чтобы не наткнуться на них по незнанию, вот и спросил)

С точки зрения администрирования - не отключай автовакуум и fsync и все будет хорошо )

В Postgres есть недостатки ? Ты сейчас серьёзно сказал ?

Вакуум?

Ну я же не знаааю, поэтому и сказал. Нельзя же воспринимать все мои слова, как слова опытного пользователя.

Я согласен, что изучается все по мере необходимости. Я работаю с Postgresql и все задачи решаю, но не сказать, что приходилось заходить слишком далеко. У postgresql есть свои преимущества и недостатки, какие то особенности, которые могут так сказать навредить, если я их буду использовать. А чтобы не наткнуться на них по незнанию, вот и спросил)

Всё равно, особенности обычно бывают по сравнению с чем-то... А для "собенности, которые могут так сказать навредить, если я их буду использовать" есть английское "слово" gotcha. Попробуйте по нему погуглить, например.

Всё равно, особенности обычно бывают по сравнению с чем-то... А для "собенности, которые могут так сказать навредить, если я их буду использовать" есть английское "слово" gotcha. Попробуйте по нему погуглить, например.

Обязательно посмотрю. Спасиб;)

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

Я думаю, что курсы от ПгПро: https://postgrespro.ru/education/courses это то, что надо.

В Postgres есть недостатки ? Ты сейчас серьёзно сказал ?

А что, нет?! о_О

select distinct appname from thetable l where app_status = 'APP_START' and not exists( select 1 from thetable l0 where l0.id = l.id and l0.appstatus <> 'APP_START' )

спасибо, но не работает select distinct appname from chname l where appstatus = 'APP_START' and not exists( select 1 from chname l0 where l0.id = l.id and l0.appstatus <> 'APP_START'); appname —---------— example_WM WM-0000000d WM-0000000e WM-0000000f WM-00000010 должен был вывести только example_WM

Я думаю, что курсы от ПгПро: https://postgrespro.ru/education/courses это то, что надо.

Спасибо)

спасибо, но не работает select distinct appname from chname l where appstatus = 'APP_START' and not exists( select 1 from chname l0 where l0.id = l.id and l0.appstatus <> 'APP_START'); appname —---------— example_WM WM-0000000d WM-0000000e WM-0000000f WM-00000010 должен был вывести только example_WM

Ну, подпили там ...

спасибо, но не работает select distinct appname from chname l where appstatus = 'APP_START' and not exists( select 1 from chname l0 where l0.id = l.id and l0.appstatus <> 'APP_START'); appname —---------— example_WM WM-0000000d WM-0000000e WM-0000000f WM-00000010 должен был вывести только example_WM

appname чем идентифицируется?

appname чем идентифицируется?

varchar

varchar

Вас не об этом спрашивали (varchar —- это тип данных, а спросили про ключи). Покажите \d таблицы, например.

\d chname Table "public.chname" Column | Type | Modifiers —---------+-----------------------+---------------------------------------------------— id | integer | not null default nextval('chname_id_seq'::regclass) appname | character varying(24) | not null default ''::character varying appstatus | character varying(48) | not null default ''::character varying Indexes: "chname_pkey" PRIMARY KEY, btree (id)

\d chname Table "public.chname" Column | Type | Modifiers —---------+-----------------------+---------------------------------------------------— id | integer | not null default nextval('chname_id_seq'::regclass) appname | character varying(24) | not null default ''::character varying appstatus | character varying(48) | not null default ''::character varying Indexes: "chname_pkey" PRIMARY KEY, btree (id)

Ах, где вы взяли эту схему. ;) Вот зачем вы используете varchar(n)? И странно, что appname ни на что не ссылается... Ну ладно, это лирика. ;) Уточните задачу: если для данного appname случилось два (или более) APP_START, оно дожно попасть в выборку?

Нет, не должно

схема тестовая, тупо разобраться с этим запросом

Так что надо ловить разожравшиеся бэкенды, цепляться к ним отладчиком и дампить мемори контексты.

Посмотрел исходники, и, похоже ограничения на размер Context’а не преусмотрено. Уже обсуждалась фича max_memory_per_process (или max_context_memory_bytes или ещё что-то такое), чтобы процесс, превысивший эту память убивался, но не тащил за собой всю базу?

То есть так? SELECT c.appname FROM chname AS c WHERE c.status = 'APP_START' AND NOT EXISTS ( SELECT 1 FROM chname AS ce WHERE ce.appname = c.appname AND ce.id <> c.id )

Отично!!!! спасибо!!!

Посмотрел исходники, и, похоже ограничения на размер Context’а не преусмотрено. Уже обсуждалась фича max_memory_per_process (или max_context_memory_bytes или ещё что-то такое), чтобы процесс, превысивший эту память убивался, но не тащил за собой всю базу?

Можно настроить демон тулз, чтобы он посылал процессу SIGTERM. По SIGTERM бэкенд выходит нормально, без перезагрузки постгреса

так, кто тут жаждал подробностей про компрессию в InnoDB? я нашёл немного времени: http://telegra.ph/Sravnenie-arhitektury-szhatiya-dannyh-v-InnoDB-i-PgPro-Enterprise-03-23

Эммм, две копии. Сжатая и разжатая. А как тогда объяснить суровое уменьшение потребления памяти мысклем при включении сжатия?

не знаю, как объяснить. мыскль вообще-то потребляет столько памяти, сколько ему скажут (innodb_buffer_pool_size)

так, кто тут жаждал подробностей про компрессию в InnoDB? я нашёл немного времени: http://telegra.ph/Sravnenie-arhitektury-szhatiya-dannyh-v-InnoDB-i-PgPro-Enterprise-03-23

о, спасибо

хотя если горячих данных меньше памяти, то сжатие скажется в меньшем RSS, да

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

да. но с общим для каждой страницы словарём

так, кто тут жаждал подробностей про компрессию в InnoDB? я нашёл немного времени: http://telegra.ph/Sravnenie-arhitektury-szhatiya-dannyh-v-InnoDB-i-PgPro-Enterprise-03-23

Спасибо!

Я правильно понял что сжатые блоки содержат пустое место?

И имеют фиксированный размер?

да и да

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

кстати, таблицы можно сжимать и расжимать обратно. чего в pgpro ee делать нельзя, как я понял из документации. но это мелочи уже

кстати, таблицы можно сжимать и расжимать обратно. чего в pgpro ee делать нельзя, как я понял из документации. но это мелочи уже

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

ok

в документации что-то невнятное на этот счёт написано

а вот надо бы ещё дописать пару банальных вещей, почему компрессия на уровне файловой системы — не панацея

так, кто тут жаждал подробностей про компрессию в InnoDB? я нашёл немного времени: http://telegra.ph/Sravnenie-arhitektury-szhatiya-dannyh-v-InnoDB-i-PgPro-Enterprise-03-23

Шах и мат pgpro?

меня попросили, я пообещал, я сделал!

давайте не будем драматизировать!

Можно настроить демон тулз, чтобы он посылал процессу SIGTERM. По SIGTERM бэкенд выходит нормально, без перезагрузки постгреса

Если вражеский запрос «в одно мгновенье» потратит гигабайт на hashjoin, то он завалит базу гораздо быстрее, чем наш cronjob обнаружит и пошлёт sigterm. Если вопрос про max_process_size не обсуждался, то я напишу в pghackers. Просто, вдруг «давно известно, что Том или Андрес запрещают делать такое».

меня попросили, я пообещал, я сделал!

Спасибо большое! Интересно было сравнить.

давайте не будем драматизировать!

Как это - не драматизировать?! У меня и так мозги набекрень, кипят и взрываются, а тут вообще чудеса: данных в памяти хранится больше, памяти потребляется меньше. До свидания, мозг, до свидания, до свидания, разум, прощай...

:)

это всё придумал Черчилль в восемнадцатом году!

А если карта сжатых данных в pgpro очень большая? Допустим сопоставима с объёмом ram - идёт её постоянное чтение с диска?

это всё придумал Черчилль в восемнадцатом году!

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

А если карта сжатых данных в pgpro очень большая? Допустим сопоставима с объёмом ram - идёт её постоянное чтение с диска?

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

Здравствуйте. Подскажите, каким образом можно разрешить заходить под определённым пользователем с определённого удалённого хоста без редактирования pg_hba.conf ? Иными словами, как можно быстро задать хост пользователя?

Я знаю, что можно прописать что-то типа host postgres all 192.168.12.10/32 md5

Но можно ли это сделать запросом к БД, как в MySQL?

Здравствуйте. Подскажите, каким образом можно разрешить заходить под определённым пользователем с определённого удалённого хоста без редактирования pg_hba.conf ? Иными словами, как можно быстро задать хост пользователя?

попробуйте alter role ... set listen_addresses = ...

У меня не роль, а отдельный пользователь

можно alter user, но в постгресе user есть роль

Но можно ли это сделать запросом к БД, как в MySQL?

нельзя

Здравствуйте! У нас буквально только что случилось непонятное. После последовательного обновления записей по 5К в одной из таблиц, один из таких запросов намертво завис. Его нельзя было прибить через pg_terminate_backend при этом логе видно было периодически LOG: invalid record length at CA3/146BC0A0: wanted 24, got 0 дальше мы сняли нагрузку с бд, и прибили через kill -9 pid процесса запроса, pg ушел в ребут и вернулся. Затем апдейт по той же таблице но по одной записи также завис. Прибили килом, затем выполнили VACUUM , вакуум "завис" затем последовательно, кил вакуума, VACUUM FULL , REINDEX TABLE, ANALYZE снова запустили таск с апдейтами, все завершилось успешно, но в логе pg опять ошибка, теперь автовакуум не может пройтись ERROR: could not open file "base/16429/128422706.1" (target block 46149768): previous segment is only 9512 blocks Mar 23 23:10:28 grus postgres[56107]: [13-2] CONTEXT: automatic vacuum of table "blizko.public.users" и это прям странно странно. Проделали снова вакуум фул, реиндекс и аналайз. Сейчас вернули нагрузку, но так и не понятно чего ждать. Версия pg 9.6.7, диски нормальные, фс в порядке. Перед килами конечно выполнянли чекпоинт. Подскажите, пожалуйста, куда копнуть?

А что тут копать, у вас почти 100% битая база —- восстановите из backup.