Live data from Hacker News

PostgreSQL 9.3 Beta 1 Released

postgresql.org

71–80 of 118 posts

Re: PostgreSQL 9.3 Beta 1 Released

#71
post #10

Earlier quoted context omitted.

Materialised views! Damn, I really could have used that a year and a bit ago..

They're a little less than what you might be expecting since they require you to manually signal when they should be updated, but otherwise they sound pretty great.

And you can't read from the matview while it's being updated, iirc.

Re: PostgreSQL 9.3 Beta 1 Released

#72

So, what's still missing in postgres? To make the responses as constructive as possible, please also specify: * Whether you currently use postgres, and what other systems you use (presumably ones that do have the feature that is missing in postgres) * Whether you currently need the feature, or whether you anticipate the need in the future, or whether you expect that other people will need it * Whether the missing fea…

I'm missing ts_rank support in the GIN index (part of the GIN generalization proposal[1]). I had to give up ranking by significance in a full-text search because it was too slow.

[1] https://wiki.postgresql.org/wiki/GIN_generalization

Re: PostgreSQL 9.3 Beta 1 Released

#73

So, what's still missing in postgres? To make the responses as constructive as possible, please also specify: * Whether you currently use postgres, and what other systems you use (presumably ones that do have the feature that is missing in postgres) * Whether you currently need the feature, or whether you anticipate the need in the future, or whether you expect that other people will need it * Whether the missing fea…

I'd love to see on-disk bitmap indexes. I noticed there was an attempt to add these around 2009 but it was abandoned after being (apparently) nearly completed. [1,2] I'd like to see these because it would make Postgres better at data warehouse applications. I've been thinking about volunteering to add them myself, but I've never looked at the Postgres codebase before, so it seems a bit ambitious. A minor feature I'd…

"on-disk bitmap indexes ... thinking about volunteering to add them myself"

That would be reasonable to do even if you don't know the internals very well. The index types (called "index access methods") are well-isolated (API-wise) from most of the rest of the code. Technically, you could even add a new index access method as an extension without even touching the core.

The exception to both of those things is the WAL recovery code, which can't be written as an extension and also requires more knowledge of the rest of the system.

But the WAL recovery code is not too bad for those that know it. So if you did the rest, then I wouldn't be surprised if someone jumped in to write it or help you write it.

"A minor feature I'd like to see is to allow ORDER BY on UPDATE statements to avoid deadlocks."

One solution here is to do a "SELECT ... FOR UPDATE" first. Unfortunately, that is redundant (and does redundant work).

Re: PostgreSQL 9.3 Beta 1 Released

#74

So, what's still missing in postgres? To make the responses as constructive as possible, please also specify: * Whether you currently use postgres, and what other systems you use (presumably ones that do have the feature that is missing in postgres) * Whether you currently need the feature, or whether you anticipate the need in the future, or whether you expect that other people will need it * Whether the missing fea…

We are currently using MS SQL Server, but have looked at the possibility of using Postgres in the future.

One major stopping point for us is the fact that on SQL Server we use a Case Insensitive, Accent Insensitive collation. Postgres doesn't support this, and apparently has no plans to.

We have many stored procedures in TSQL which are built around the assumption of CI,AI. Converting these will be a lot of work, but the lack of CI,AI collation would be by far the biggest pain point.

Re: PostgreSQL 9.3 Beta 1 Released

#75

Earlier quoted context omitted.

The Rails/ActiveRecord bug tracker? edit: the underlying connector might be a better idea to start with, as it'll need to expose the fields somehow before an ORM can take advantage of them.

Looks like work has started on the underlying connector: https://bitbucket.org/ged/ruby-pg/issue/161/add-support-for-...

I wouldn't say "work has started" when the bug has just been reported.

Re: PostgreSQL 9.3 Beta 1 Released

#76

Earlier quoted context omitted.

Wow, that is awesome and is something I've been worrying about recently. However, there is a second part that is still missing that would allow for actual postgresql application development. There needs to be a way to check all constraints and report all failures, rather than just stopping at the first error. Without that, users submit data, get an error for one field, fix it and resubmit, get an error for the next f…

"check all constraints and report all failures" Interesting point. Foreign key failures are usually the result of a program bug. Unique and exclusion[1] constraints depend on concurrent actions, and can't be caught ahead of time as easily. So I assume you are mostly talking about CHECK constraints. Also, we're talking about a single statement, which probably means a single table. It does sound like a good idea to val…

Yes and no. Yes in that I am talking specifically about check constraints when I say that we have to duplicate them all in our apps. You can't really duplicate the others. But no in that I don't mean to validate only check constraints and report all failures, ideally it would do unique and FK too. If there's an underlying reason that isn't feasible, then doing all the check constraints at once would certainly be a big improvement though. We're already in the position of having data validation type checks done separately from uniques now, so that would get users of our apps the current behaviour while letting us delete a bunch of code.

Re: PostgreSQL 9.3 Beta 1 Released

#77

Earlier quoted context omitted.

I'd love to see on-disk bitmap indexes. I noticed there was an attempt to add these around 2009 but it was abandoned after being (apparently) nearly completed. [1,2] I'd like to see these because it would make Postgres better at data warehouse applications. I've been thinking about volunteering to add them myself, but I've never looked at the Postgres codebase before, so it seems a bit ambitious. A minor feature I'd…

"on-disk bitmap indexes ... thinking about volunteering to add them myself" That would be reasonable to do even if you don't know the internals very well. The index types (called "index access methods") are well-isolated (API-wise) from most of the rest of the code. Technically, you could even add a new index access method as an extension without even touching the core. The exception to both of those things is the WA…

Thank you for the encouragement! Odds are I'll be doing a lot of data warehouse work in the next 6 months, so I'll be motivated to get involved.

EDIT: One thing that intimidated me was browsing through the mailing list thread in my [1] above and seeing people ask about lock correctness. That seems like something where you'd need a broad view of the system. I might give it a try anyway, though. One thing about Postgres is your team is incredibly helpful, professional, and kind. Tom Lane has given me all kinds of answers on the mailing list in the past. I have enough good will for the project that I'm pretty much just looking for an excuse to contribute something. It would be an honor to give something back, and I feel safe asking for help from you all.

Re: PostgreSQL 9.3 Beta 1 Released

#78
post #54

So, what's still missing in postgres? To make the responses as constructive as possible, please also specify: * Whether you currently use postgres, and what other systems you use (presumably ones that do have the feature that is missing in postgres) * Whether you currently need the feature, or whether you anticipate the need in the future, or whether you expect that other people will need it * Whether the missing fea…

I use Postgres for pretty much every project possible, as well as using Oracle for consulting clients. The main feature which I'd like the PG development team to look at next is implementing a more comprehensive partitioning solution. As far as remaining competitive with the commercial database vendors, the one thing that is the primary reason I have seen for enterprises choosing to reluctantly pay for Oracle over us…

"Active/active clustering of DB nodes"

This is being developed as Postgres-XC. They released version 1.0 in June 2012.

"Postgres-XC is an open source project to provide a write-scalable, synchronous multi-master, transparent PostgreSQL cluster solution. "

http://postgres-xc.sourceforge.net/

Re: PostgreSQL 9.3 Beta 1 Released

#79
post #14

Earlier quoted context omitted.

I'd love to hear about them too. I've seen some O'Reilly books but they've been long time ago.

There is a really old O'Reilly book, I think, but there is also an O'Reilly book called "PostgreSQL: Up and Running" that came out last year that covers 9.2.

I just finished with it. It's actually quite good to get you started with Postgres. Besides installing and command line usage it introduces many Postgres features and how they differ from MySQL, Oracle and the like.

Re: PostgreSQL 9.3 Beta 1 Released

#80

Earlier quoted context omitted.

Yeah but since it's just being added, it precludes "NoSQL guys" having built upon it, which is the original complaint.

Another intepretation of zapov's comment is that it's a shame the NoSQL projects didn't try achieving their goals by building postgres extensions (or even adding new features). A reasonable question. MongoDB could have focused their energies on really good JSON support in postgres and making postgres sharding easier.

An interesting interpretation, which I had not considered. Thank you.
Post reply on HN