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

PostgreSQL 10 Beta 1 Released

postgresql.org

Post reply on HN
Print view View original

101–110 of 172 posts

Re: PostgreSQL 10 Beta 1 Released

#101

Post by anarazel »

snuxoll wrote: post #97
anarazel wrote: post #54

Earlier quoted context omitted.

Postgres dev here. > but what I really want from Postgres is a proper equivalent to MSSQL's FILESTREAM. What sizes of files and such are you interested in? What kind of read/write patterns? I do think we need some improvements in the area. Not enough that I'll drop the other stuff I'm working on, which I think is higher priority, but enough to discuss approaches and review patches. It'd be cool if you could comment o…

Small files, 25-50K on average (images of patient charts), and they're all they're all write-once read-many.

Hm, in that case, what stops you from just using a bytea column?

Re: PostgreSQL 10 Beta 1 Released

#102

Post by gshulegaard »

threeseed wrote: post #92
gshulegaard wrote: post #75

Earlier quoted context omitted.

I would say that it isn't configured to scale like Mongo out of the box...but that doesn't mean it can't. You can go outside of Postgres core to get multi-master solutions with easy sharding and clustering...with the open sourcing of CitusDB and 2nd Quadrant's pglogical and BDR extensions there are options out there. You can also roll your own (if you really want)...and it is relatively approachable to do so using bu…

None of what you posted is built in and thus supported by the vendor. That may not matter to you but it's a deal breaker for those of us in enterprises. We can't just be rolling our own versions of PostgreSQL and we can't use CitusDB when it is not supported by other vendors for use with their products. The point still remains that after all these year PostgreSQL's scalability story is still a mess.

I think you might be confused somewhat...PostgreSQL doesn't have "a vendor". The history of Postgres starts at UC Berkeley and now has the PostgreSQL Global Development Group which is a mixture of contributors both community and corporate sponsored:

https://www.postgresql.org/community/contributors/

Of that group, both 2nd Quadrant and CitusDB are represented...so in a way you could say their support is "by the vendor". Not to mention EnterpriseDB which also has support options.

> we can't use CitusDB when it is not supported by other vendors for use with their products.

CitusDB is no longer a fork, it's an extension...this means so long as your other vendors products support Postgres, they support CitusDB. More over, CitusDB itself will sell you an Enterprise package.

> The point still remains that after all these year PostgreSQL's scalability story is still a mess.

If by mess you mean specifically there is no knob and dial arrangement in the core of Postgres I would agree.

But within the core of PostgreSQL there are primitives which make scaling approachable (I myself am working on a data ingestion process that utilizes table partitioning and hand rolled sharding for PostgreSQL).

And there are now a plethora of extensions and tools provided by core contributors such as 2nd Quadrant and CitusDB to offer somewhat out of the box solutions and they even come with support.

PostgreSQL is not the right tool for every job and the replication/clustering area has been a a sore spot for Postgres in the past. But it certainly isn't bereft of options now...and the inclusion of logical replication in this beta is only the first step in bringing these options closer/into the core.

Re: PostgreSQL 10 Beta 1 Released

#103

Post by snuxoll »

anarazel wrote: post #101
snuxoll wrote: post #97

Earlier quoted context omitted.

Small files, 25-50K on average (images of patient charts), and they're all they're all write-once read-many.

Hm, in that case, what stops you from just using a bytea column?

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.

Re: PostgreSQL 10 Beta 1 Released

#104

Post by sqeaky »

X86BSD wrote: post #100
sqeaky wrote: post #89

Earlier quoted context omitted.

Database plus Copy-On-Write file systems sound like a bad idea. I am imagining a modest 100gb database being re-written for every change. I am sure there is some way to work around this, but wouldn't this be the default behavior with a typical database and typical COW file system?

You might be interested in reading this paper: https://people.freebsd.org/~seanc/postgresql/scale15x-2017-p...

I am interested and I appreciate the thought and link, however these appear to be the slides to a talk without the actual talk. If so they are of limited use because the slides never have all the information the presenter has, and that information is often just a summary.

Is this the correct talk: https://youtu.be/dwMQXLOXUco?t=5380 ?

Re: PostgreSQL 10 Beta 1 Released

#105

Post by cryptonector »

walrus wrote: post #56
pilif wrote: 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…

What's the significance of the `update .. set (..) = row (..) ..` syntax? update comment set modified = now(), body = 'edited comment' where id = 123; vs update comment set (modified, body) = row (now(), 'edited comment') where id = 123; It doesn't seem to provide any new functionality, just a minor difference in syntax.

Looks like a purely cosmetic change. Scroll down to the bottom of https://www.postgresql.org/docs/10.0/static/sql-update.html to see the only related difference from https://www.postgresql.org/docs/9.6/static/sql-update.html .

Re: PostgreSQL 10 Beta 1 Released

#106

Post by cryptonector »

sqeaky wrote: post #89
X86BSD wrote: post #43

Earlier quoted context omitted.

You would get compression with Postgres running on ZFS.

Database plus Copy-On-Write file systems sound like a bad idea. I am imagining a modest 100gb database being re-written for every change. I am sure there is some way to work around this, but wouldn't this be the default behavior with a typical database and typical COW file system?

First, you have to make sure the page sizes for the FS and DB match. That's a critical requirement. But yes, you'll get write expansion twice.

Re: PostgreSQL 10 Beta 1 Released

#107

Post by [deleted] »

crgwbr wrote: post #35

Will having logical replication make doing a DB version upgrade in production easier? We're using Postgres 9.4 on RDS right now, and there doesn't seem to be an upgrade path that doesn't involve some downtime.

[deleted]

Re: PostgreSQL 10 Beta 1 Released

#109

Post by phonon »

cygned wrote: post #84
saurik wrote: post #82

Earlier quoted context omitted.

I was expecting that presentation to be stuff you were missing, but the presentation is saying that essentially every feature they describe is implemented in PostgreSQL. Of the SQL:2011 ones, only one wasn't (temporal tables), and even the SQL:2016 features had partial support (with the summary slide at the end of other features they didn't do in detail having stuff that looks familiar in a PostgreSQL context). Do yo…

I really would like to use Temporal Tables (slides 137 and following) to say like 'give me the record of last week'. I can of course do that already manually, but it is tedious and I hope it will be faster if implemented directly.

https://github.com/arkhipov/temporal_tables seems like a good option?

Re: PostgreSQL 10 Beta 1 Released

#110

Post by X86BSD »

sqeaky wrote: post #104
X86BSD wrote: post #100

Earlier quoted context omitted.

You might be interested in reading this paper: https://people.freebsd.org/~seanc/postgresql/scale15x-2017-p...

I am interested and I appreciate the thought and link, however these appear to be the slides to a talk without the actual talk. If so they are of limited use because the slides never have all the information the presenter has, and that information is often just a summary. Is this the correct talk: https://youtu.be/dwMQXLOXUco?t=5380 ?

Yes, sorry about that, that is the corresponding talk to the slides. Thanks for pointing that out.
Post reply on HN