cstore_fdw
pgBackRest
Our great sponsors
cstore_fdw | pgBackRest | |
---|---|---|
6 | 13 | |
1,738 | 2,209 | |
0.4% | 5.1% | |
2.6 | 9.2 | |
about 3 years ago | 3 days ago | |
C | C | |
Apache License 2.0 | GNU General Public License v3.0 or later |
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.
cstore_fdw
-
Moving a Billion Postgres Rows on a $100 Budget
Columnar store PostgreSQL extension exists, here are two but I think I’m missing at least another one:
https://github.com/citusdata/cstore_fdw
https://github.com/hydradatabase/hydra
You can also connect other stores using the foreign data wrappers, like parquet files stored on an object store, duckdb, clickhouse… though the joins aren’t optimised as PostgreSQL would do full scan on the external table when joining.
-
Anything can be a message queue if you use it wrongly enough
I'm definitely not from Citus data -- just a pg zealot fighting the culture war.
If you want to reach people who can actually help, you probably want to check this link:
https://github.com/citusdata/cstore_fdw/issues
-
Pg_squeeze: An extension to fix table bloat
That appears to be the case:
https://github.com/citusdata/cstore_fdw
>Important notice: Columnar storage is now part of Citus
-
Ingesting an S3 file into an RDS PostgreSQL table
either we go for RDS, but we stick to the AWS handpicked extensions (exit timescale, citus or their columnar storage, ... ),
-
Postgres and Parquet in the Data Lke
Re: performance overhead, with FDWs we have to re-munge the data into PostgreSQL's internal row-oriented TupleSlot format again. Postgres also doesn't run aggregations that can take advantage of the columnar format (e.g. CPU vectorization). Citus had some experimental code to get that working [2], but that was before FDWs supported aggregation pushdown. Nowadays it might be possible to basically have an FDW that hooks into the GROUP BY execution and runs a faster version of the aggregation that's optimized for columnar storage. We have a blog post series [3] about how we added agg pushdown support to Multicorn -- similar idea.
There's also DuckDB which obliterates both of these options when it comes to performance. In my (again limited, not very scientific) benchmarking of on a customer's 3M row table [4] (278MB in cstore_fdw, 140MB in Parquet), I see a 10-20x (1/2s -> 0.1/0.2s) speedup on some basic aggregation queries when querying a Parquet file with DuckDB as opposed to using cstore_fdw/parquet_fdw.
I think the dream is being able to use DuckDB from within a FDW as an OLAP query engine for PostgreSQL. duckdb_fdw [5] exists, but it basically took sqlite_fdw and connected it to DuckDB's SQLite interface, which means that a lot of operations get lost in translation and aren't pushed down to DuckDB, so it's not much better than plain parquet_fdw.
This comment is already getting too long, but FDWs can indeed participate in partitions! There's this blog post that I keep meaning to implement where the setup is, a "coordinator" PG instance has a partitioned table, where each partition is a postgres_fdw foreign table that proxies to a "data" PG instance. The "coordinator" node doesn't store any data and only gathers execution results from the "data" nodes. In the article, the "data" nodes store plain old PG tables, but I don't think there's anything preventing them from being parquet_fdw/cstore_fdw tables instead.
[0] https://github.com/citusdata/cstore_fdw
-
Creating a simple data pipeline
The citus extension for postgresql. https://github.com/citusdata/cstore_fdw
pgBackRest
-
pgBackRest: PostgreSQL S3 backups
This tutorial explains how to backup PostgreSQL database using pgBackRest and S3.
-
Anything can be a message queue if you use it wrongly enough
This isn't theoretical; many companies do PostgreSQL async 1:N physical replication, by using e.g. https://pgbackrest.org/ to have the primary push WAL segment files (a.k.a. "the last n milliseconds of packets" in the write-ahead log) as objects to S3, and then to have all read-replicas fetch from S3 and replay.
> You could do even better if you out-of-band signal the readiness so you do not need to poll while idle.
S3 and its clones have "object lifecycle notifications", where you can be informed by a push-based mechanism whenever a new object is put into the bucket.
But — what do you have to do, to get these notifications?
Subscribe to a message queue that S3 puts them into.
-
Kubernetes postgres backups
I haven't explored the territory in awhile but for bare-metal, you can't go wrong with Percona Distribution, which includes pgBackRest and a minimal web-ui. No one ever got fired for using Percona, etc.
- pgBackRest - Reliable PostgreSQL Backup & Restore
- pgBackRest - have you used it and what was your experience?
-
How to backup database
Check out pgBackRest
-
Use One Big Server
I found this approach pretty cool in that regard: https://github.com/pgbackrest/pgbackrest
- Moving from Oracle to Postgres, what should I know?
-
How do you back up your databases?
Something like PG barman or pg backrest could be good for you on the Postgres side.
-
Cloud SQL is not great
Backups are limited. These days, pgbackrest is the go-to backup solution for PostgreSQL, and having used it I am very impressed so far. It provides full backups, differential, and incremental, as well as archiving of WAL segments for point in time recovery. It allows great flexibility in schedules and destinations for backups, how long to keep backups for, how many full backups. For example, you can have backups made to a local disk, and other backups to an external S3-compatible bucket, each with their own settings and schedules (e.g., scheduled via cron).
What are some alternatives?
ZLib - A massively spiffy yet delicately unobtrusive compression library.
Barman - Barman - Backup and Recovery Manager for PostgreSQL
odbc2parquet - A command line tool to query an ODBC data source and write the result into a parquet file.
wal-g - Archival and Restoration for databases in the Cloud
zstd - Zstandard - Fast real-time compression algorithm
docker-postgres-wale - Postgres docker container with WALE-E installed
cute_headers - Collection of cross-platform one-file C/C++ libraries with no dependencies, primarily used for games
wal-e - Continuous Archiving for Postgres
delta - An open-source storage framework that enables building a Lakehouse architecture with compute engines including Spark, PrestoDB, Flink, Trino, and Hive and APIs
pghoard - PostgreSQL® backup and restore service
parquet_fdw - Parquet foreign data wrapper for PostgreSQL
postgres - Docker Official Image packaging for Postgres