PostgreSQL Parallel Query v2
rhaas.blogspot.com
PostgreSQL Parallel Query v2
1–10 of 44 posts
Re: PostgreSQL Parallel Query v2
#2The relationship between EnterpriseDB and the at-large Postgres community has always intrigued me. Why do they turn over to the community what they could make part of their proprietary fork? Maybe they make a lot of money consulting and not just licenses and general at-large adoption is good for that side of business.
Re: PostgreSQL Parallel Query v2
#3That is really an amazing amount of work that has gone into this next release.
This is really getting Postgres up to par with the commercial offerings, and hopefully it keeps progressing for v11.
It's especially important now since servers with more and more cores are becoming the norm.
Re: PostgreSQL Parallel Query v2
#4The relationship between EnterpriseDB and the at-large Postgres community has always intrigued me. Why do they turn over to the community what they could make part of their proprietary fork? Maybe they make a lot of money consulting and not just licenses and general at-large adoption is good for that side of business.
Part of it is that they build the basis for features, and work on getting them into core, so it makes their value added features in their proprietary fork easier to maintain. Sometimes giving back and having an easier time maintaining your own fork is worth the effort and costs associated I guess. I for one appreciate it.
Re: PostgreSQL Parallel Query v2
#5The relationship between EnterpriseDB and the at-large Postgres community has always intrigued me. Why do they turn over to the community what they could make part of their proprietary fork? Maybe they make a lot of money consulting and not just licenses and general at-large adoption is good for that side of business.
I think their secret sauce is Oracle compatibility, so if Postgres runs better, they run better.
Re: PostgreSQL Parallel Query v2
#6The relationship between EnterpriseDB and the at-large Postgres community has always intrigued me. Why do they turn over to the community what they could make part of their proprietary fork? Maybe they make a lot of money consulting and not just licenses and general at-large adoption is good for that side of business.
I think their secret sauce is Oracle compatibility, so if Postgres runs better, they run better.
And the Oracle compatibility piece breaks so much that it would never get merged into community Postgres.
Re: PostgreSQL Parallel Query v2
#7Earlier quoted context omitted.
I think their secret sauce is Oracle compatibility, so if Postgres runs better, they run better.
And the Oracle compatibility piece breaks so much that it would never get merged into community Postgres.
Even if it didn't, for all the work they put into the community version one can't begrudge them trying to make a living on the enterprise side.
Re: PostgreSQL Parallel Query v2
#8The relationship between EnterpriseDB and the at-large Postgres community has always intrigued me. Why do they turn over to the community what they could make part of their proprietary fork? Maybe they make a lot of money consulting and not just licenses and general at-large adoption is good for that side of business.
I have never used EnterpriseDB and I am only aware of it from a distance but it has always struck me as the ideal open source arrangement. Sure, EnterpriseDB is never going to have the revenue numbers of Oracle but their management and business teams should have a much easier time sleeping at night. I think it is great that EnterpriseDB has identified that it is better for their company to exist as part of a healthy ecosystem instead of trying to pave paradise so to speak.
Re: PostgreSQL Parallel Query v2
#9The relationship between EnterpriseDB and the at-large Postgres community has always intrigued me. Why do they turn over to the community what they could make part of their proprietary fork? Maybe they make a lot of money consulting and not just licenses and general at-large adoption is good for that side of business.
I have never used EnterpriseDB and I am only aware of it from a distance but it has always struck me as the ideal open source arrangement. Sure, EnterpriseDB is never going to have the revenue numbers of Oracle but their management and business teams should have a much easier time sleeping at night. I think it is great that EnterpriseDB has identified that it is better for their company to exist as part of a healthy…
A healthy relationship with open source projects is a great way to attract talent and gain goodwill.
Re: PostgreSQL Parallel Query v2
#10Besides parallel queries (specifically parallel index scans), the Postgres 10 feature I'm most looking forward to is the work Andres Freund has done on using LLVM to JIT compile expressions[0]. Based on the the layout of the database I work on[1], an insane amount of CPU goes to processing of partial index predicates. If the improvements are anywhere near what is being described in the mailing list, we're going to start saving a ton of money on CPU.
Parallel index scans will be an absolutely massive win for us. Currently Postgres does not perform any sort of prefetching. When performing an index scan, this results in serialized random I/O. In our case, queries wind up using ~1/10th the I/O they could be using if there were to do more I/O in parallel. We are expecting a dramatic speedup just from parallel index scans. This is in addition to the bugfix in 9.6 (we're currently on 9.5) which added proper support for index only scans over partial indexes. That bugfix should also result in a pretty large speedup for a lot of our queries.
As soon as Postgres 10 comes out, we are immediately going to upgrade. There are just so many huge wins for us.
[0] https://www.postgresql.org/message-id/20161206034955.bh33pae...
[1] https://blog.heapanalytics.com/running-10-million-postgresql...