There is the cstore extension, which is pretty much "native" (at some point these terms start to lose meaning... it's running in the same process space and transaction aware, etc.)
Re:Postgres and Parquet in the data lake
by skeletal88 on Thursday May 05, 2022 @05:13AM
(#31271208)
No need to change the database itself, these kind of features belong in foreign data wrappers. You can already treat csv files as tables or access tables in other databases(mysql, oracle etc)
With a massive performance impact (for reading csvs anyway).
It's a matter of how much you want to keep using postgres versus if you want interactive-level performance.
I'm not saying one is better or worse than the other but they are definitely not the same.
Re:Postgres and Parquet in the data lake
by tomnipotent on Thursday May 05, 2022 @03:56AM
(#31270751)
> Does this even make sense?
Yes, but may not be practical. A non-trivial amount of code makes assumptions about the underlying data layout, so things like the cost-based optimizer and MVCC would basically need to be rewritten.
> Wouldn't it be nice if Postgresql could gain a native new storage engine which serializes columnar data as parquet files? Does this even make sense?
Surely that's exactly what parquet_fdw is?
DuckDB already has fine Parquet support and I find it really helpful.