#prog #db #postgresql #sql #article
«Ленивый сахар» PostgreSQL
SQL - декларативный язык - то есть вы описываете "что" хотите получить, а СУБД сама решает, "как" именно она будет это делать. Некоторые из них при этом позволяют им "подсказывать", как именно лучше выполнять запрос, но PostgreSQL - нет.
Тем не менее, "синтаксический сахар" некоторых языковых конструкций позволяет не только писать меньше кода (учите матчасть!), но и добиться, что ваша база будет делать часть вычислений "лениво", только при фактической необходимости.
«Ленивый сахар» PostgreSQL
SQL - декларативный язык - то есть вы описываете "что" хотите получить, а СУБД сама решает, "как" именно она будет это делать. Некоторые из них при этом позволяют им "подсказывать", как именно лучше выполнять запрос, но PostgreSQL - нет.
Тем не менее, "синтаксический сахар" некоторых языковых конструкций позволяет не только писать меньше кода (учите матчасть!), но и добиться, что ваша база будет делать часть вычислений "лениво", только при фактической необходимости.
Хабр
«Ленивый сахар» PostgreSQL
Блиц, Блиц, скорость без границ! SQL - декларативный язык - то есть вы описываете "что" хотите получить, а СУБД сама решает, "как" именно она будет это делать. Некоторые из них при этом позволяют им...
👍2
#prog #db #article
Durability and Redo Logging, или немного о том, как базы данных обеспечивают сохранность данных при помощи redo log (aka "write ahead log" — кмк, довольно сбивающий с толку термин).
Durability and Redo Logging, или немного о том, как базы данных обеспечивают сохранность данных при помощи redo log (aka "write ahead log" — кмк, довольно сбивающий с толку термин).
#prog #db #article
Push vs. Pull-Based Loop Fusion in Query Engines (pdf)
Для того, чтобы исполнить SQL-запрос, движок базы данных сначала должен скомпилировать его из декларативного представления в конкретный план, который уже можно интерпретировать. Технически ничто не мешает исполнять операторы один за другим, но для любых сколько-нибудь реалистичных нагрузок этот вариант не подходит ввиду копирования и перемещения в памяти больших наборов данных. Для составления этого конкретного плана есть два различных — более эффективных, чем наивный — подхода.
Pull-based подход — который исторически был придуман ранее — предполагает композицию операторов, каждый из которых предоставляет метод next. Данные материализуются по мере последовательных вызовов next у самого верхнего оператора, который вызывает next у нижележащего, тот, в свою очередь, вызывает next у оператора ещё ниже и так далее вплоть до непосредственного источника данных. В данном подходе направления потока управления и потока данных противоположны. Если вам это всё кажется похожим на итератор, то интуиция вас не подводит — это соответствует паттерну "итератор" из ООП, и данный подход был описан под названием Volcano Iterator model.
Альтернативный подход — push-based — предполагает составление цепочки операторов, в которых источник данных активно передаёт данные вверх вплоть до корневого SELECT. Не смотря на то, что этот подход кажется менее естественным, порождаемый им код имеет более простой граф потока управления и потому лучше подвергается оптимизациям компилятора, что делает этот подход значительно быстрее pull-based варианта — на порядок.
...Ну или так утверждалось ранее в работах, которые цитируют авторы этой статьи. Они утверждают, что данное мнение необоснованно, поскольку в предшествующих сравнениях сравнивались версии push-based с оптимизациями компилятора — с инлайнингом — и pull-based без оптимизаций. Как они сами пишут:
Recent papers [42, 30] seem to suggest that this push-model consistently leads to better query processing performance than the pull model, even though no direct, fair comparisons are provided. One of the main contributions of this paper is to debunk this myth. As we show, if compared fairly, push and pull based engines have very similar performance, with individual strengths and weaknesses, and neither is a clear winner. Push engines have in essence only been considered in the context of query compilation, conflating the potential advantages of the push paradigm with those of code inlining. To compare them fairly, one has to decouple these aspects.
Для того, чтобы достичь этого самого decoupling, авторы показывают соответствие между операторами запросов и комбинаторами коллекций (такими, как std::iter или LINQ) и далее экспериментируют с кодом, который реализует различные подходы на коллекциях. Такой подход они считают обоснованными, поскольку фактически именно к этому и сводятся базы данных, размещающие данные в оперативной памяти, а в базах данных, размещающих данные на диске, время на пересылку данных из диска в память перекрывает разницу в производительности подходов.
Авторы показывают, что эти два подхода, будучи подверженными одному и тому же набору оптимизаций, показывают схожую производительность — push-based обычно быстрее, но незначительно. Более того, в запросах, в которых можно утилизировать ленивость — с операторами LIMIT и MERGE JOIN — все преимущества push-based подхода вылетают в трубу, давая значительно худшую производительность. Сравнения проводились как на микробенчмарках с простыми запросами, так и с эквивалентами запросов из тестов TPC-H.
Второй вклад этой статьи — предложенный ими новый подход для движков запросов, который хитрым способом объединяет pull- и push-based варианты. Цитируя статью:
Push vs. Pull-Based Loop Fusion in Query Engines (pdf)
Для того, чтобы исполнить SQL-запрос, движок базы данных сначала должен скомпилировать его из декларативного представления в конкретный план, который уже можно интерпретировать. Технически ничто не мешает исполнять операторы один за другим, но для любых сколько-нибудь реалистичных нагрузок этот вариант не подходит ввиду копирования и перемещения в памяти больших наборов данных. Для составления этого конкретного плана есть два различных — более эффективных, чем наивный — подхода.
Pull-based подход — который исторически был придуман ранее — предполагает композицию операторов, каждый из которых предоставляет метод next. Данные материализуются по мере последовательных вызовов next у самого верхнего оператора, который вызывает next у нижележащего, тот, в свою очередь, вызывает next у оператора ещё ниже и так далее вплоть до непосредственного источника данных. В данном подходе направления потока управления и потока данных противоположны. Если вам это всё кажется похожим на итератор, то интуиция вас не подводит — это соответствует паттерну "итератор" из ООП, и данный подход был описан под названием Volcano Iterator model.
Альтернативный подход — push-based — предполагает составление цепочки операторов, в которых источник данных активно передаёт данные вверх вплоть до корневого SELECT. Не смотря на то, что этот подход кажется менее естественным, порождаемый им код имеет более простой граф потока управления и потому лучше подвергается оптимизациям компилятора, что делает этот подход значительно быстрее pull-based варианта — на порядок.
...Ну или так утверждалось ранее в работах, которые цитируют авторы этой статьи. Они утверждают, что данное мнение необоснованно, поскольку в предшествующих сравнениях сравнивались версии push-based с оптимизациями компилятора — с инлайнингом — и pull-based без оптимизаций. Как они сами пишут:
Recent papers [42, 30] seem to suggest that this push-model consistently leads to better query processing performance than the pull model, even though no direct, fair comparisons are provided. One of the main contributions of this paper is to debunk this myth. As we show, if compared fairly, push and pull based engines have very similar performance, with individual strengths and weaknesses, and neither is a clear winner. Push engines have in essence only been considered in the context of query compilation, conflating the potential advantages of the push paradigm with those of code inlining. To compare them fairly, one has to decouple these aspects.
Для того, чтобы достичь этого самого decoupling, авторы показывают соответствие между операторами запросов и комбинаторами коллекций (такими, как std::iter или LINQ) и далее экспериментируют с кодом, который реализует различные подходы на коллекциях. Такой подход они считают обоснованными, поскольку фактически именно к этому и сводятся базы данных, размещающие данные в оперативной памяти, а в базах данных, размещающих данные на диске, время на пересылку данных из диска в память перекрывает разницу в производительности подходов.
Авторы показывают, что эти два подхода, будучи подверженными одному и тому же набору оптимизаций, показывают схожую производительность — push-based обычно быстрее, но незначительно. Более того, в запросах, в которых можно утилизировать ленивость — с операторами LIMIT и MERGE JOIN — все преимущества push-based подхода вылетают в трубу, давая значительно худшую производительность. Сравнения проводились как на микробенчмарках с простыми запросами, так и с эквивалентами запросов из тестов TPC-H.
Второй вклад этой статьи — предложенный ими новый подход для движков запросов, который хитрым способом объединяет pull- и push-based варианты. Цитируя статью:
👍2
#prog #sql #db
You Need More Constraints
Чеклист ограничений на таблицы в SQL, которые почти наверняка имеют смысл для ваших данных, вместе с конкретными примерами.
You Need More Constraints
Чеклист ограничений на таблицы в SQL, которые почти наверняка имеют смысл для ваших данных, вместе с конкретными примерами.
❤6
There will be no singularity
https://dx.tips/oops-database
#prog #db #web #article
Stop building databases
Или о том, почему вам может потребоваться БД на веб-клиенте. Автор предлагает специализированную БД SQLSync, построенную поверх SQLite.
Stop building databases
Или о том, почему вам может потребоваться БД на веб-клиенте. Автор предлагает специализированную БД SQLSync, построенную поверх SQLite.
sqlsync.dev
Stop building databases
Join me as we take a look at common application data patterns, and how they relate to the inner-workings of databases. In this post, we discuss data caching, indexing, optimistic mutations, and recursive cache invalidation. We will see how life might be easier…
🔥2🌚1
#prog #db #article
The part of PostgreSQL we hate the most
Или о том, как криво в PostgreSQL реализован MVCC и как это сказывается на производительности, особенно на нагрузках с большим количеством записей.
The part of PostgreSQL we hate the most
Или о том, как криво в PostgreSQL реализован MVCC и как это сказывается на производительности, особенно на нагрузках с большим количеством записей.
Andy Pavlo - Carnegie Mellon University
The Part of PostgreSQL We Hate the Most
As much as Andy loves PostgreSQL, there is one part that is terrible and causes many headaches for people. Learn what it is and why it sucks.
❤7
#prog #db #article
Nine ways to shoot yourself in the foot with PostgreSQL
Статья от 23 апреля 2023, так что некоторые пункты могут быть неактуальны (один уже устарел).
Nine ways to shoot yourself in the foot with PostgreSQL
Статья от 23 апреля 2023, так что некоторые пункты могут быть неактуальны (один уже устарел).
philbooth.me
Nine ways to shoot yourself in the foot with PostgreSQL
Previously for Extreme Learning,
I discussed
all the ways I've broken production using healthchecks.
In this post
I'll do the same for PostgreSQL.
I discussed
all the ways I've broken production using healthchecks.
In this post
I'll do the same for PostgreSQL.
Блог*
#prog #db #article The part of PostgreSQL we hate the most Или о том, как криво в PostgreSQL реализован MVCC и как это сказывается на производительности, особенно на нагрузках с большим количеством записей.
#prog #db #article
Yes, PostgreSQL has problems, but we’re sticking with it!
Статья о том, как обойти некоторые из упомянутых недостатков MVCC. Не без рекламы своего продукта, но вроде штука полезная.
Yes, PostgreSQL has problems, but we’re sticking with it!
Статья о том, как обойти некоторые из упомянутых недостатков MVCC. Не без рекламы своего продукта, но вроде штука полезная.
Andy Pavlo - Carnegie Mellon University
Yes, PostgreSQL Has Problems. But We’re Sticking With It!
Andy explores ways to optimize PostgreSQL for each of the problems caused by the implementation of multi-version concurrency control in PostgreSQL.
#prog #db #menacingopensource
github.com/frectonz/pglite-fusion
Embed an SQLite database in your PostgreSQL table. AKA multitenancy has been solved.
(thanks @nosingularity)
github.com/frectonz/pglite-fusion
Embed an SQLite database in your PostgreSQL table. AKA multitenancy has been solved.
(thanks @nosingularity)
🥴12👌2👍1
#prog #db #article
PSA: SQLite WAL checksums fail silently and may lose data
(thanks @nosingularity)
PSA: SQLite WAL checksums fail silently and may lose data
In the previous posts I mentioned that SQLite does not do checksums by default, but it has checksums in WAL mode. However, on checksum errors, instead of raising error, it drops all the subsequent frames. Even if they are not corrupt. This is not a bug; it’s intentional.
(thanks @nosingularity)
🌚4
#prog #abnormalprogramming #db #article
Making Postgres 42,000x slower because I am unemployed
(thanks @nosingularity)
Making Postgres 42,000x slower because I am unemployed
<...> I decided someone needed to try to create a Postgres configuration optimized to process queries as slowly as possible. Why? I am not sure, <...>
I can’t make this too easy. This is a Postgres tuning challenge, not a throttle-your-CPU-to-one-megahertz-and-delete-indexes challenge, so all changes must be on parameters in postgresql.conf. Additionally, the database will still need to have the capability to process at least one transaction within a reasonable amount of time—it would be too simple just to grind Postgres to a halt.
(thanks @nosingularity)
🌚7