Live data from Hacker News

PostgreSQL 10 Beta 1 Released

postgresql.org

121–130 of 172 posts

Re: PostgreSQL 10 Beta 1 Released

#121
post #118
post #13

While everybody is going to be rightfully excited about the logical replication, for me personally, CREATE STATISTICS and the new ROW syntax for UPDATE amount to the additions that have the probably biggest effect on me ever since I moved to postgres exclusively when 7.1 was released. Especially CREATE STATISTICS (wonderful explanation here https://www.postgresql.org/docs/10.0/static/multivariate-sta... ) is the one…

As exciting as this is (and it really is) it's yet another thing that explodes the number of possibilities for optimization. It's getting towards the point of unmanageability and I hope there will be a movement towards, if not auto-tuning databases, assistive tools for exploring both this and indexing possibilities.

CMU's DBMS is trying to do this: http://pelotondb.io

Re: PostgreSQL 10 Beta 1 Released

#122
post #119

Earlier quoted context omitted.

My major issue with bytea is two fold, the same oid issue that you have with LOB's (we have 10's of billions of pages) so you're forced to less than optimal solutions like table inheritance for large numbers of records, plus it severely bloats the size of the heap file making a VACCUM FULL take a century if needed.

> so you're forced to less than optimal solutions like table inheritance for large numbers of records Would the "native table partitioning" feature introduced in this release be a solution (or, at least, more optimal) for this? Alternately, if you want to go off-heap, what about using Foreign Data Wrappers ( https://wiki.postgresql.org/wiki/Foreign_data_wrappers#File_... )? These two both sound like they might solve…

The native table partitioning removes one of the headaches of inheritance, but it mostly only relieves some of the administrative headaches - the foreign key issues remain.

fdw's are great, but they don't participate in replication - which is a pretty big issue. Unfortunately, the "proper" way to do this would be with a custom type, but I can't find any way you could write one with the extension API that wouldn't be stored in the database heap (you could create some native functions similar to the existing LOB functions, but then you run into atomicity issues again).

Honestly, this would be easy to write if the extension API supported off-heap storage of custom types - though I understand there's a ton of technical complexity in implementing such a feature.

Re: PostgreSQL 10 Beta 1 Released

#123
post #120

unrelated to this particular release, but since we're talking about postgres... how do people find the ability to write stored procedures and functions in languages other than just SQL? I'm coming from a MSSQL shop and curious how writing a query in python for example has benefited anyone if at all -- did you / can you use modules like numpy or pandas in a postgres python procedure?

Python under PG can do anything python can do.. but that said, just because you CAN import numpy/pandas and go to town, doesn't mean you SHOULD . In fact you probably really shouldn't :) That said, we use python inside of PG, and it's awesome. It's not really any more powerful than PG/SQL(their built-in language) i.e. in terms of what you can do in the DB itself. Our main app is also python, so we have a continuity o…

Sometimes I'd rather do python magic than self join correlated sub-queries or write window functions and have it all become a convoluted mess. But I see your point.

edit: i'm still trying to train myself to think in a relational way.

Re: PostgreSQL 10 Beta 1 Released

#125

Earlier quoted context omitted.

Or they want to allow for case-insensitivity of some data, like for example email addresses on login forms. As much as postgres is overall better than MySQL in so many ways, it's still ridiculously difficult to set things up such that SELECT id FROM users WHERE email='foo@example.com' returns the same result as SELECT id FROM users WHERE email='Foo@example.com'

Just lowercase everything. Not that hard.

Uppercase is the master race

Re: PostgreSQL 10 Beta 1 Released

#126

Earlier quoted context omitted.

https://www.github.com/JerrySievert/MongoLike that said, I actually use partial JSONB updates on a regular basis, but I tend to use PLV8 to do the heavy lifting.

What is the point of posting that ? (1) It's a proof of concept, (2) it hasn't been updated in 3 years and (3) it still isn't the same syntax as MongoDB. The point still remains that PostgreSQL isn't just a 1-1 replacement for MongoDB which is pretty common sense to me anyway.

Wow, that's a pretty hostile response.

1) it's a proof of concept that others have improved upon to show that you can indeed replace the functionality of mongo that most developers tend to rely on.

2) neither has mongodb at that level

3) that's correct, you need to actually use the term SELECT when you use the functions

and you are correct, pg is missing the random data loss that comes with mongo. it will never be 1-1 in regards to that.

EDITING TO ADD:

the important part is the note (the bulk of the comment) that I'm updating partial JSONB data on a very regular basis, and do it using PLV8, getting rid of the need for an unreliable database and instead using exactly what this news story is about.

Re: PostgreSQL 10 Beta 1 Released

#127
post #86
post #40

Earlier quoted context omitted.

Get involved in the mailing list and start discussion on these features and how they would help you.

I fear I cannot contribute a lot in my extremely limited time. Is there a 'getting started' guide somewhere?

Honestly you don't even have to submit a single patch to contribute.

Here is the developer's FAQ: https://wiki.postgresql.org/wiki/Developer_FAQ

I know the feeling of having extremely limited time, i'm in the same boat. But I use Postgres every day with my startup, and we lean very heavy on the database (not by volume of data, just by complexity of the problems). I've reviewed a few patches that I wanted to see get into Postgres, and contributed to discussions on the mailing list. That's about the extent I am able to do at the moment, but it's better than nothing. More reviewers are never a bad thing.

Re: PostgreSQL 10 Beta 1 Released

#128

So it looks like PostgreSQL will finally be web scale ;) (ducks and runs)

That, i suppose, was meant to be a joke. see https://www.youtube.com/watch?v=b2F-DItXtZs and just replace mysql with pg.

Yes, it was a reference to that. My comment is currently sitting at -2. I'm still getting the hang of Hacker News' sense of humor. On Slashdot, I would be at +5. Ho hum.

Anyway, just to make my intentions clear, I love Postgres, have used it for over a decade, and have yet to use MongoDB or any other NoSQL database.

Re: PostgreSQL 10 Beta 1 Released

#129

Earlier quoted context omitted.

That, i suppose, was meant to be a joke. see https://www.youtube.com/watch?v=b2F-DItXtZs and just replace mysql with pg.

Yes, it was a reference to that. My comment is currently sitting at -2. I'm still getting the hang of Hacker News' sense of humor. On Slashdot, I would be at +5. Ho hum. Anyway, just to make my intentions clear, I love Postgres, have used it for over a decade, and have yet to use MongoDB or any other NoSQL database.

In general, strive for substantive and constructive comments on HN. If you've got that, a little humor added in can be appreciated. Comments that are submitted only for humor value (which you knew yours was, given your parenthetical addendum) are likely to be less appreciated on HN than on other sites.

Here's a recent thread where this has been discussed:

https://news.ycombinator.com/item?id=13760333

There are likely others that describe it better, but I don't have them at hand.

Edit to add: Of course there are. Here's some comments by 'dang on the topic:

https://hn.algolia.com/?query=author:dang%20humor&sort=byPop...

Re: PostgreSQL 10 Beta 1 Released

#130
post #9
post #8

Earlier quoted context omitted.

Citus is building functionality on PostgreSQL to provide sharding for data sets too large for a single machine. There aren't really any PG 10 features that duplicate that. Some of the new PG features such as increased query parallelism allow for better utilization of single-machine resources. Other features such as logical replication may allow for some horizontal scaling by splitting read workloads across replicas,…

Aggregate push down to foreign servers seems to overlap with Citus. It's not as transparent, but you could have a dataset sharded across several PG instances, mount them all into a master with foreign data wrappers, and UNION them (for some queries) to aggregate across the set.

BTW, you can also create partitions as foreign tables: https://www.postgresql.org/docs/10.0/static/sql-createforeig...
Post reply on HN