cstore_fdw
Disruptor
Our great sponsors
cstore_fdw | Disruptor | |
---|---|---|
6 | 30 | |
1,738 | 17,020 | |
0.4% | 0.9% | |
2.6 | 5.4 | |
about 3 years ago | 4 months ago | |
C | Java | |
Apache License 2.0 | Apache License 2.0 |
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
Disruptor
-
Gnet is the fastest networking framework in Go
https://lmax-exchange.github.io/disruptor/#_what_is_the_disr.... Unfortunately IIUC writing this in Go still prevents the spin-locked acceptor thread from achieving the kind of performance you could get in a non-GC language, unless you chose to disable GC, so I'd guess Envoy is still faster.
https://gnet.host/docs/quickstart/ it's nice that you can use this simply though. Envoy is kind of tricky to setup with custom filters, so most of the time it's just a standalone binary.
[0] https://blog.envoyproxy.io/envoy-threading-model-a8d44b92231...
[1] https://lmax-exchange.github.io/disruptor/#_what_is_the_disr...
-
A lock-free ring-buffer with contiguous reservations (2019)
See also the Java LMAX Disruptor https://github.com/LMAX-Exchange/disruptor
I've built a similar lock-free ring buffer in C++11 https://github.com/posterior/loom/blob/master/doc/adapting.m...
-
JEP Draft: Deprecate Memory-Access Methods in Sun.misc.Unsafe for Removal
"Why we chose Java for our High-Frequency Trading application"
https://medium.com/@jadsarmo/why-we-chose-java-for-our-high-...
LMAX Disruptor customers
https://lmax-exchange.github.io/disruptor/
Among many other examples.
-
LMAX Disruptor – High Performance Inter-Thread Messaging Library
Current documentation
https://lmax-exchange.github.io/disruptor/
-
Progress on No-GIL CPython
LMAX Disruptor has on their wiki that average latency to send a message from one thread to another at 53 nanoseconds. For comparison a mutex is like 25 nanoseconds and more if Contended but a mutex is point to point synchronization.
The great thing about it is that multiple threads can receive the same message without much more effort.
https://github.com/LMAX-Exchange/disruptor/wiki/Performance-...
https://gist.github.com/rmacy/2879257
I am dreaming of language that is similar to Smalltalk that stays single threaded until it makes sense to parallise.
I am looking for problems to parallelism that are not big data. Parallelism is like adding more cars to the road rather than increasing the speed of the car. But what does a desktop or mobile user need to do locally that could take advantage of the mathematical power of a computer? I'm still searching.
- Disruptor 4.0.0 Released
-
Anything can be a message queue if you use it wrongly enough
Database config should be two connection strings, 1 for the admin user that creates the tables and anther for the queue user. Everything else should be stored in the database itself. Each queue should be in its own set of tables. Large blobs may or may not be referenced to an external file.
Shouldn't a message send be worst case a CAS. It really seems like all the work around garbage collection would have some use for in-memory high speed queues.
Are you familiar with the LMAX Disruptor? Is is a Java based cross thread messaging library used for day trading applications.
https://lmax-exchange.github.io/disruptor/
-
Any library you would like to recommend to others as it helps you a lot? For me, mapstruct is one of them. Hopefully I would hear some other nice libraries I never try.
Disruptor for inter-thread messaging
-
Measuring how much Rust's bounds checking actually costs
I have never worked in any industries where a perf margin was that small. It is funny, in HFT there are folks using Lmax (Java) and then you have folks writing their own TCP/IP stacks on FPGAs to do trading.
What are some alternatives?
ZLib - A massively spiffy yet delicately unobtrusive compression library.
JCTools
odbc2parquet - A command line tool to query an ODBC data source and write the result into a parquet file.
Agrona - High Performance data structures and utility methods for Java
zstd - Zstandard - Fast real-time compression algorithm
fastutil - fastutil extends the Java™ Collections Framework by providing type-specific maps, sets, lists and queues.
cute_headers - Collection of cross-platform one-file C/C++ libraries with no dependencies, primarily used for games
MPMCQueue.h - A bounded multi-producer multi-consumer concurrent queue written in C++11
delta - An open-source storage framework that enables building a Lakehouse architecture with compute engines including Spark, PrestoDB, Flink, Trino, and Hive and APIs
Eclipse Collections - Eclipse Collections is a collections framework for Java with optimized data structures and a rich, functional and fluent API.
parquet_fdw - Parquet foreign data wrapper for PostgreSQL
Javolution