pgreplay
blog
pgreplay | blog | |
---|---|---|
2 | 11 | |
205 | 9 | |
- | - | |
4.2 | 6.0 | |
7 months ago | 3 months ago | |
C | ||
GNU General Public License v3.0 or later | Creative Commons Zero v1.0 Universal |
Stars - the number of stars that a project has on GitHub. Growth - month over month growth in stars.
Activity is a relative number indicating how actively a project is being developed. Recent commits have higher weight than older ones.
For example, an activity of 9.0 indicates that a project is amongst the top 10% of the most actively developed projects that we are tracking.
pgreplay
-
Versioning data in Postgres? Testing a Git like approach
pgreplay parses not the WAL Write Ahead Log but the log file: https://github.com/laurenz/pgreplay
From "A PostgreSQL Docker container that automatically upgrades your database" (2023) https://news.ycombinator.com/item?id=36748041 :
pgkit wraps Postgres PITR backup and recovery:
-
Real Application Testing on 🚀YugabyteDB with 🐘pgreplay
This blog was just to verify that it works with YugabyteDB. Check pgreplay documentation for more, all works the same in YugabyteDB. If you want to capture a workload from connections on multiple database nodes, each one will have their logfile. You can merge them. The Session ID (the 6th field in the csvlog built from start time and backend pid will probably not collide with another one, but you can make it unique by concatenating a node number if you want). The replay connects to one node, but though a HA proxy the connections can be distributed to multiple ones. All depends on what you want to capture and wh you want to replay. Capturing from PostgreSQL and replaying to YugabyteDB is also a good way to check that all works the same without performance regressions.
blog
- Versioning data in Postgres? Testing a Git like approach
-
A Different Type of SQL Recursion with PostgreSQL
Originally published at https://github.com/vb-consulting/blog/discussions/1
A follow up on this article was written today
[Recursion with PostgreSQL, Follup 1, Perfomances](https://github.com/vb-consulting/blog/discussions/4)
-
Recursion with PostgreSQL Follow-Up 3 - Finding the Right Path
In my previous article, I managed to get some really crazy performances in tree processing by using PostgreSQL recursive procedural-style function.
- Recursive Hierarchical Queries in SQL: A Deep Dive into Employee Level
- Which Way .NET Developer?
-
Recursion with PostgreSQL, Follup 1, Perfomances
I wrote a follow-up on yesterday's article on tree processing and recursion with PostgreSQL. This one: https://github.com/vb-consulting/blog/discussions/1
SQL was never intended for this kind of stuff; I'm sure that Fabian Pascal will tell us all about it.
And indeed, recursive CTEs are awful, confusing, and severely limited ... but they look cool and smart, and smart people use them (I hate them).
In any case, I used a procedural approach to this problem and, with a few smart optimizations, managed to squeeze some really spectacular performances (757K tree records with 20K unique nodes in just 5 seconds without any indexes, so it probably can go even faster).
What are some alternatives?
pgkit - Pgkit - Backup, PITR and recovery management made easy
Logidze - Database changes log for Rails