Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

PostgreSQL 17

postgresql.org

Post reply on HN
Print view View original

121–130 of 153 posts

Re: PostgreSQL 17

#121

Post by systems »

bigger_cheese wrote: post #120
systems wrote: post #118

Earlier quoted context omitted.

PowerBI might be the only BI solution with a decent functional language DAX is supper powerful, if you design your datawarehouse as a proper stat scheme, there is nothing you cannot calculate using DAX Nothing in the market is even close, most BI tool have magic expression language, DAX is a proper language

I'm sure it can work but I've found it hard to slot into our use cases. Power BI's trending is one thing I have really struggled with the limitations it has. For one of my use cases (industrial plant data) we often want to trend timeseries data on a common xaxis with uniquely scaled yaxis. i.e Temperature, Pressure, Flow Rate, Fill height etc all have differently scaled yaxis but common xaxis. Something like this exa…

sorry weird question, did you keep changing this link? was one of the link on powerbi.tips

can you put that back, for some reason my browser history lost it , or something weird happened, not sure what it is

Re: PostgreSQL 17

#122

Post by ktosobcy »

dewey wrote: post #40
ktosobcy wrote: post #26

Would be awesome if PostgreSQL would finally add support for seamless major version upgrade…

Maybe https://github.com/pgautoupgrade/docker-pgautoupgrade is interesting for you.

I heard about that project but it still somewhat convoluted. Imagine being able to simply use "postgres:latest" or better yet "postgres:15" and switch to "postgres:16" and it would just update (like any other minor version does, or any other db, like mysql, does)

Re: PostgreSQL 17

#123

Post by ktosobcy »

ellisv wrote: post #28
ktosobcy wrote: post #26

Would be awesome if PostgreSQL would finally add support for seamless major version upgrade…

I'm curious what you feel is specifically missing.

Being able to simply switch from "postgres:15" to "postgres:16" in docker for example (I'm aware about pg_autoupdate but it's external and I'm a bit iffy about using it)

What's more, even outside of docker running `pg_upgrade` requires both version to be present (or having older binary handy). Honestly, having the previous version logic to load and process the database seems like it would be little hassle but would improve upgrading significantly...

Re: PostgreSQL 17

#124

Post by pnt12 »

sgarland wrote: post #111
openrisk wrote: post #83

There was LAMP and then MERN and MEAN etc. and then there was Postgres. Its not quite visible yet, but all this progres by postgres (excuse the pun) on making JSON more deeply integrated with relational principles will surely at some point enable a new paradigm, at least for full stack web frameworks?

We’re already in a new paradigm, one in which web devs are abandoning referential integrity guarantees in favor of not having to think about data modeling. I’d say they’re then surprised when their DB calls are slow (nothing to do with referential integrity, just the TOAST/DETOAST overhead), but since they also haven’t experienced how fast a DB with local disks and good data locality can be, they have no idea.

Can you elaborate on what's TOAST/DETOAST?

Re: PostgreSQL 17

#125

Post by davidrowley »

pnt12 wrote: post #124
sgarland wrote: post #111

Earlier quoted context omitted.

We’re already in a new paradigm, one in which web devs are abandoning referential integrity guarantees in favor of not having to think about data modeling. I’d say they’re then surprised when their DB calls are slow (nothing to do with referential integrity, just the TOAST/DETOAST overhead), but since they also haven’t experienced how fast a DB with local disks and good data locality can be, they have no idea.

Can you elaborate on what's TOAST/DETOAST?

The Oversized-Attribute Storage Technique. https://www.postgresql.org/docs/17/storage-toast.html

Re: PostgreSQL 17

#126

Post by baq »

brunoqc wrote: post #98
kiwicopple wrote: post #4

Another amazing release, congrats to all the contributors. There are simply too many things to call out - just a few highlights: Massive improvements to vacuum operations: "PostgreSQL 17 introduces a new internal memory structure for vacuum that consumes up to 20x less memory." Much needed features for backups: "pg_basebackup, the backup utility included in PostgreSQL, now supports incremental backups and adds the pg…

I batch import XMLs, CSVs and mssql data into postgresql. I'm pretty sure I could read them when needed with fdw. Is it a good idea? I think it can be slow but maybe I could use materialized views or something.

check out clickhouse. you might like it.

Re: PostgreSQL 17

#127

Post by ssfak »

nojvek wrote: post #107

I wish postgres supports parquet file imports and exports. COPY command with csv is really slooooooooow. Even BINARY is quite slow and bandwidth heavy. I wonder how open postgres is and what kind of pull requests postgres team considers? I'd like to learn how to contribute to PG in baby steps and eventually get to a place where I could contribute substantial features.

Using the pg_duckdb[1] is an option, if you can install extensions on your setup.

[1]. https://github.com/duckdb/pg_duckdb

Re: PostgreSQL 17

#128

Post by jaakl »

bradford wrote: post #72
gigatexal wrote: post #24

Earlier quoted context omitted.

What do you love so about PowerBI? I’ve not looked at it very closely. I’ve worked with Tableau and Looker and LookerPro. All of which seemed fine. Is it a home run if the end users aren’t on Windows or using Excel? I’m thinking about the feature where you can use a SQLServer DB as a data source to Excel.

> What do you love so about PowerBI? For a large portion of my career, the dashboarding solutions I've worked with have followed a similiar model: they provide a presentation layer directly on top of a query of some kind (usually, but not always, a SQL query). This seems like a natural next step for organizations that have a lot of data in one spot, but no obvious way of visualizing it. But, after implementing and ma…

The problem of semantic models what I've seen in tools like Looker, Tableau and Qlik (very probably same for PowerBI) is that they are tightly coupled to the tool itself, work within them only. Now you want "modern data system" then you want them decoupled and implemented with an open semantic model which is then accessable by data consumers in Google spreadsheets, Jupyter notebooks and whatever BI/Analytics/reporting tools your stakeholder uses or prefers. There are very new solutions for this like dbt semantic models; their only issue is that they tend to be so fresh that bigger orgs (where they do make most sense) may be shy on implementing them yet. To the original topic - not sure how much PG17 can be used in these stacks, usually much better are analytical databases - BigQuery, Snowflake, maybe Redshift, future (Mother)Duck(db)

Re: PostgreSQL 17

#129

Post by lukaslalinsky »

Wow, it finally has failover support for logical replication slots. That was biggest reason why I couldn't depend on logical replication, since the master DB failover handling was too complex for me to deal with.

Re: PostgreSQL 17

#130

Post by garyclarke27 »

ellisv wrote: post #27
pestaa wrote: post #10

Very impressive changelog. Bit sad the UUIDv7 PR didn't make the cut just yet: https://commitfest.postgresql.org/49/4388/

I've been waiting for "incremental view maintenance" (i.e. incremental updates for materialized views) but it looks like it's still a few years out.

Agreed big disappointment that "incremental view maintenance" is taking so long to get into the core - despite several IVM extensions. For me this is by far the most important capability missing from Postgres.
Post reply on HN