Перечитал документацию. К сожалению у PostgreSQL нет таких опций, а решение materialize/inline принимает «божественный» планировщик. Зимой отгреб из-за этого проблему, потому-что после какого-то сбора статистики планировщик внезапно перестал делать condition pushdown из основного запроса в CTE.
Перефразирую вопрос.
У Тома фраза звучит как: сурогратный ключй — не настоящий ключ, а ерунда на постном масле. В этом же предложении есть про первичный ключ на основе последовательности, как один из вариантов определения «настоящего» первичного ключа. А в терминах хабровской статьи первичный ключ на основе последовательности — это суррогатный ключ.
Возможно, просто, наложились термин «суррогатный ключ» и какой-то альтернативный перевод слова «surrogate».
Логика статьи понятна. Помогите разобраться с терминологией. Всю жизнь думал суррогатный ключ — искусственно созданный ключ для упрощения доступа (напимер serial или uuid вместо составного естественного ключа).
И тут, внезапно, натыкаюсь на объяснение Тома Кайта, почему в Оракле нет on update:
«Primary keys are supposed to be imutable, never changing, constant. It is an excessively bad practice to have to update them ever. If there is a 0.00001% chance you will have to update a primary key — then it is not a primary key, its a surrogate key and you need to find the true primary key (even if you have to make it up via a sequence) » ( asktom.oracle.com/pls/asktom/f?p=100:11:0::::P11_QUESTION_ID:5773459616034 )
Здесь, просто «surrogate key» не «суррогатный ключ», что-то другое?
LEFT JOIN specifications_history AS specification_history
ON specification_history.id = specification_detail.entity_history_id
AND specification_history.specification_id = ANY(specification_parts.ids)
но, ANY(specification_parts.ids) — это ересь. При соединениях сравнения выполняются построчно, потому внутри ANY(specification_parts.ids) все-равно всегда будет ровно одна строка. А значит, условие полностью равносильно с… AND specification_history.specification_id = specification_parts.ids
Это я прекрасно знаю. Вопрос, здесь использовалось расширение или использовался общий тип «массив чего-то-там». Будет ли разница (в плане или скорости), если включить расширение?
Подскажите, в данном случае INTEGER[] будет просто массивом целых чисел или включится расширение intarray ( https://www.postgresql.org/docs/9.6/static/intarray.html )?
Судя по форумам tablespace на RAM-диске дает очень высокую вероятность убить всю базу.
"...losing any tablespace would prevent the database server from starting,
even if it was only for temporary things" https://www.postgresql.org/message-id/51806248.60401%40darrenduncan.net
Сообщение датировано 2013 годом. Интересно, как сейчас дела обстоят?
С помощью схем в PG можно логически группировать таблицы. Писать запросы не мешает, так как всегда можно указать все схемы в schema_search_path сессии и не указывать при именовании таблиц.
Как бонус можно создать таблицы с одинаковым именем в разных схемах для горячих и исторических данных. Тогда можно не меняя запросы подключатся между ними просто указав параметры в сессии.
Подскажите, откуда взялось, что «Дело в том, что PostgreSQL для каждой временной таблицы создает временный файл…»? Нигде в документации об этом не написано.
Повлияет ли на производительность, если временную таблицу создавать в tablespace на RAM-диске?
На на выходе нужен html документ, потому делаем в 2 этапа:
1) ручками запускаем преобразование формул, как описано в http://tex.stackexchange.com/questions/233963/convert-mathtype-and-ms-word-equations-equations-to-latex
2) при загрузке на сервер, скармливаем через unoconv документ LibreOffice
Формулы показываем через MathJax. Он пришел на замену mimetex.
C TeX долго морочились, но, в конце-концов, печатные копии стали рендрить через wkhtmltopdf
Сравните работу с TEXT у MySQL и Postgresql. У MySQL это настоящий сборник ограничений. Читаем документацию в PG:
The storage requirement for a short string (up to 126 bytes) is 1 byte plus the actual string, which includes the space padding in the case of character. Longer strings have 4 bytes of overhead instead of 1. Long strings are compressed by the system automatically, so the physical requirement on disk might be less. Very long values are also stored in background tables so that they do not interfere with rapid access to shorter column values.
и
Tip: There is no performance difference among these three types [CHAR, VARCHAR, TEXT], apart from increased storage space when using the blank-padded type, and a few extra CPU cycles to check the length when storing into a length-constrained column
А разве MathType не позволяет конвертировать формулы из одного вида в другой? По крайней мере мы им пользуемся, чтобы перегнать все формулы (и старого и нового вида) в tex, а потом отображать через MathJAX или mimetex.
Наверное, "not in"? C in проблем нет
У Тома фраза звучит как: сурогратный ключй — не настоящий ключ, а ерунда на постном масле. В этом же предложении есть про первичный ключ на основе последовательности, как один из вариантов определения «настоящего» первичного ключа. А в терминах хабровской статьи первичный ключ на основе последовательности — это суррогатный ключ.
Возможно, просто, наложились термин «суррогатный ключ» и какой-то альтернативный перевод слова «surrogate».
И тут, внезапно, натыкаюсь на объяснение Тома Кайта, почему в Оракле нет on update:
«Primary keys are supposed to be imutable, never changing, constant. It is an excessively bad practice to have to update them ever. If there is a 0.00001% chance you will have to update a primary key — then it is not a primary key, its a surrogate key and you need to find the true primary key (even if you have to make it up via a sequence) » ( asktom.oracle.com/pls/asktom/f?p=100:11:0::::P11_QUESTION_ID:5773459616034 )
Здесь, просто «surrogate key» не «суррогатный ключ», что-то другое?
но, ANY(specification_parts.ids) — это ересь. При соединениях сравнения выполняются построчно, потому внутри ANY(specification_parts.ids) все-равно всегда будет ровно одна строка. А значит, условие полностью равносильно с… AND specification_history.specification_id = specification_parts.ids
"...losing any tablespace would prevent the database server from starting,
even if it was only for temporary things" https://www.postgresql.org/message-id/51806248.60401%40darrenduncan.net
Сообщение датировано 2013 годом. Интересно, как сейчас дела обстоят?
Как бонус можно создать таблицы с одинаковым именем в разных схемах для горячих и исторических данных. Тогда можно не меняя запросы подключатся между ними просто указав параметры в сессии.
Повлияет ли на производительность, если временную таблицу создавать в tablespace на RAM-диске?
В одной из версий Excel был забавный баг, когда, в некоторых случаях, при печати значения на графиках отличались от значений в исходном файле.
1) ручками запускаем преобразование формул, как описано в http://tex.stackexchange.com/questions/233963/convert-mathtype-and-ms-word-equations-equations-to-latex
2) при загрузке на сервер, скармливаем через unoconv документ LibreOffice
Формулы показываем через MathJax. Он пришел на замену mimetex.
C TeX долго морочились, но, в конце-концов, печатные копии стали рендрить через wkhtmltopdf
Для этих целей есть не очень живой db-charmer (До Rails 3 включительно) и воплне живой octopus (есть поддержка Rails 4)
Сравните работу с TEXT у MySQL и Postgresql. У MySQL это настоящий сборник ограничений. Читаем документацию в PG:
и