Live data from Hacker News

Postgresql 9.6: Support parallel aggregation

postgresql.org

61–64 of 64 posts

Re: Postgresql 9.6: Support parallel aggregation

#61
post #55
post #14

Earlier quoted context omitted.

> SELECT EXPLAIN ANALYZE will tell if its relevant for you That assumes I run PostgreSQL already, which I don't. I am interested in possibly switching at some point if it's worthwhile, but it's hard to muster the effort to do concerted testing of a representative sample of my data, including possibly changing how queries are done to take advantage of specific features, when I have little information to go on. Not tha…

If you aren't using it now, and thus don't know how fast or slow it would be on your data and queries, why would you care about percentage speed ups? It could be a 1% speed up from insanely fast to slightly more insanely fast, or a 100% speed up from unbearably slow to just extremely annoyingly slow. I gather that people considering migrating who want some reassurance before investing time in testing should be more i…

>> I am interested in possibly switching at some point if it's worthwhile

> If you aren't using it now, and thus don't know how fast or slow it would be on your data and queries, why would you care about percentage speed ups?

I'm working under the assumption that similar operations between PostgreSQL and MySQL for operations that aren't using an advanced feature that the other plainly doesn't support will be roughly comparable in performance. I understand this isn't true, but it's useful in that it gives me a baseline to work with when reasoning without forcing me to migrate my application (or at least a significant portion of the data) to PostgreSQL just to test. If I'm then confronted with a feature that one supports and the other doesn't that has the capability to in some cases reduce the query time by an order of magnitude, then it's starts approaching the criteria needed for me to invest that time to see if it's worth migrating.

> I gather that people considering migrating who want some reassurance before investing time in testing should be more interested in such things things as benchmarks that show whether PostgreSQL can saturate your hardware for various query types

Isn't that exactly what this is? Throwing CPU cores at aggregating data to reduce time? I asked for benchmarks regarding this specific feature, to see what type of gain we were talking about with this. I didn't ask for comparisons to other databases because those benchmarks are generally harder to perform fairly, so I would have been (and am) happy with comparative gain benchmarks.

Re: Postgresql 9.6: Support parallel aggregation

#62
post #58

Earlier quoted context omitted.

I wish they would build a RDS alternative. I would use them in a heartbeat. There are all these companies/startups who are not in the target market for consulting... But who would gladly pay for hosted postgres.

Just a little heads-up: Postgres is very easy to run on your own and even in the default configuration runs well even for a considerable amount of users. Over here, we only started to seriously thinking about what we're doing once we were handling in the order of 10K transactions per second. Once you are at that level, you're probably going to need optimizations specific to your application and a generic database hos…

I have a fairly sophisticated docker VM with wal-e, replication and everything running. Yes - I am aware of what you say.

Hosting the dB has never been the knowledge about central piece of application. you may disagree (and I respect that), but for me it has been similar to building a RAID-10 dedicated server vs using AWS.

You can argue that maintaining data resiliently is a critical part of the organization - but at what stage? In the first 3 years of a startup, you are iterating the product. You are pretty much agonizing over drop rates, conversion rates for every single minute of your life. The fact that data will crash NEEDS to come a distant second.

Dropbox has only just moved out of AWS. Storage was probably the most critical part of Dropbox, but it chose (rightly) to focus on customers first.

What you are talking about will come - but it will come after some time. And till then I would love to pay some postgres devs to run a hosted dB for me...like RDS.

Re: Postgresql 9.6: Support parallel aggregation

#63
post #26

Earlier quoted context omitted.

Out of curiosity what does it matter if your postgres download is via http or https? Is there any benefit of hiding your download from prying eyes?

To put it another way it's less about prying eyes and more about MitM attacks.

I really do wonder whether there's a verified "path of trust" where I can get a copy of e.g. Debian (without knowing what the canonical website for Debian is), install it on a machine, connect it to the internet and update it, without being at all vulnerable to a MitM attack at any step.

I would be suspicious that it's the very first step that poses the most danger: there's little way to know whether minor-distro-X is "properly" hosted at minordistrox.com or distrox.org or even distrox.github.io, other than by blindly trusting the relative PageRanks of each.

---

Something that would be very nice, I think, would be a way to rely on the package-signing infrastructure of the OS you've already got (and trust), to guarantee for you the copies of any new OS images—even for different OSes!—you download. Sort of the same way you download new versions of OSX through the Mac App Store, but going a bit further.

Now that I think about it, the browser-preloaded HSTS list might do the trick... if it was coupled with a mapping of 'important well-known downloads' to a single (HSTS-preloaded) domain you should be allowed to get those downloads from. (Presumably with heuristic detection, so it could find "something looking mostly, from its metadata, like a Debian ISO image.") Then your browser would just tell you you're being phished if you're trying to get a Debian ISO from debianisamazing.info.

Re: Postgresql 9.6: Support parallel aggregation

#64
post #47

Earlier quoted context omitted.

Please check out our Aiven ( https://aiven.io ). Managed & hosted pay-per-hour PostgreSQL that is available on GCE, AWS and DigitalOcean.

Very cool! I would definitely use you guys once my aws credits run out. Quick suggestion - please make your pricing front and center. If you didn't tell me on HN, I would have dropped off on your home page. Check cloudways pricing page for a very similar business model pricing page.

We now have a full price list available, see https://aiven.io/postgresql#pricing for details. Thanks for the feedback!
Post reply on HN