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

New in PostgreSQL 10

wiki.postgresql.org

Post reply on HN
Print view View original

191–200 of 258 posts

Re: New in PostgreSQL 10

#191

Post by user5994461 »

jacques_chester wrote: post #83
Thaxll wrote: post #44

Earlier quoted context omitted.

No it's not, say that have 2TB of logs daily, good luck designing that with a regular RDMS without sharding / clustering / re-balancing capabilities.

I expect either of Citus or Greenplum can deal with that kind of volume. Citus acts as an extension, Greenplum is descended from an earlier fork (now merging its back to mainline as part of overall development). Citus specifically cite analytics and write throughput as their strengths. I believe them. They do seem to charge for shard rebalancing and some other features. Greenplum comes with an inbuilt data science to…

And citus will be a nightmare to setup and maintain, for what elasticsearch could have done easier and better out of the box. Use the right tool for the job.

Re: New in PostgreSQL 10

#192

Post by garyclarke27 »

ianamartin wrote: post #140
hardwaresofton wrote: post #96

Does anyone have any use cases where PostgreSQL falls down/loses to other DB systems? I know sharding/replication has long been a sticking point, but what else is there? Why do people still choose MySQL/MariaDB/Oracle over PostgreSQL at all?

Dynamic SQL in Postgres is really frustrating. I understand why. It's because you shouldn't fucking write SQL that writes SQL. On the other hand, sometimes you just have to. SQL Server . . . I won't say it makes it easy, but it doesn't make it so goddam impossible. If I lived in a world without Postgres, I would use SQL Server without thinking twice. MySQL/Maria I'm not fond of, and I kind of don't want to touch them…

Dynamic SQL is easy in Postgres Just create a simple pl/pgsql function that takes a text argument and executes it. Works for me perfectly for anything I need such as building tables views functions etc.

Re: New in PostgreSQL 10

#193

Post by kochthesecond »

irrational wrote: post #154
alceta wrote: post #19

If anyone even remotely involved with the maintenance and development of pg reads this thread - Thank you! - for all your efforts in building and improving a first class product that keeps me amazed at the strides it takes with each major. release.

Truly. We've recently moved from Oracle (after using it for 15 years) to Postgresql. It's like a breath of fresh air. The documentation for Postgres is unbelievably superior to Oracle. So far its performance is equal to or better than Oracle. We had to go through and rewrite thousands of queries, but the sql syntax of Postgres was always simpler and more logical than the equivalent in Oracle (I think Oracle has too m…

I think most Oracle installs are from the days ram was limited and incredibly expensive.

Right now anyone can afford a db server with 128gb ram, enough to solve most problems #YourDataFitsInRam

Re: New in PostgreSQL 10

#194

Post by jeltz »

mrfusion wrote: post #69

What does native partitioning do?

It basically just adds a convenient syntax for creating partitions plus adds automatic tuple routing (routing inserts on the partitioned table to the right partition). This is for most users not a huge improvement over using PostgreSQL's table inheritance to implement partitioning, but it is a very important stepping stone for implementing competitive partitioning in PostgreQL. There are lots of promising patches in the PostgreSQL 11 release cycle which improve on the native partitioning, making it useful for more users.

Re: New in PostgreSQL 10

#195

Post by Manozco »

KayEss wrote: post #166
Manozco wrote: post #117

Earlier quoted context omitted.

Yes, in many cases (until I stopped using it), it messed up my benchmarks. I was testing some queries, and often it was: - pgserver fast, returns 10000 rows, pgcli takes time to parse -> result: total time 10s - pgserver slow, returns 1 row, pgcli instant -> result: total time 10 sec. As we are working in efficient C/C++, our internal time to parse the query set is closer to psql than pgcli, so we tend to prefer the…

For bench marking and optimising queries you almost certainly want `EXPLAIN ANALYZE`. That will give you what you want about what Postgres thinks and the time actually taken for the query.

Yes, sure, but executing the query a couple of times on the command line is also something I do

Re: New in PostgreSQL 10

#197

Post by mrfusion »

jeltz wrote: post #194
mrfusion wrote: post #69

What does native partitioning do?

It basically just adds a convenient syntax for creating partitions plus adds automatic tuple routing (routing inserts on the partitioned table to the right partition). This is for most users not a huge improvement over using PostgreSQL's table inheritance to implement partitioning, but it is a very important stepping stone for implementing competitive partitioning in PostgreQL. There are lots of promising patches in…

Thanks. I guess I meant to ask what a partition is used for? When is it useful to use one and why?

Re: New in PostgreSQL 10

#198

Post by jacques_chester »

user5994461 wrote: post #191
jacques_chester wrote: post #83

Earlier quoted context omitted.

I expect either of Citus or Greenplum can deal with that kind of volume. Citus acts as an extension, Greenplum is descended from an earlier fork (now merging its back to mainline as part of overall development). Citus specifically cite analytics and write throughput as their strengths. I believe them. They do seem to charge for shard rebalancing and some other features. Greenplum comes with an inbuilt data science to…

And citus will be a nightmare to setup and maintain, for what elasticsearch could have done easier and better out of the box. Use the right tool for the job.

I was pointing out that 2TB/day is not a very high write volume for modern OSS RDBMSes, especially distributed ones.

As for elasticsearch, I have found it to be temperamental. The "out of the box" experience was usually unhappy. For logging I've seen people move to other tools (splunk, stackdriver) more than once.

Re: New in PostgreSQL 10

#199

Post by pgaddict »

ComodoHacker wrote: post #184
bonesmoses wrote: post #134

Earlier quoted context omitted.

Cross-column statistics are one of my favorites. The way Postgres 10 handles it is really a _huge_ advancement that addresses a painful edge case that has been around for ages. https://blog.2ndquadrant.com/pg-phriday-crazy-correlated-col...

To be honest, skewed data problem can be addressed with partitioning in many cases. Cross-column statistics is a great feature nevertheless.

Yes, but partitioning also has a number of limitations that may be quite undesirable. Like inability to create UNIQUE constraints or primary keys, for example.

Re: New in PostgreSQL 10

#200

Post by pgaddict »

pbnjay wrote: post #39

> Cross-column Statistics Holy crap I didn't even know this was feasible much less in development! Can't wait to test this out, as significant amount of my data sets have these kinds of relationships. Parallel query will also be great for certain queries I do regularly. Been looking forward to this! Thank you Thank you to all the devs that had a part of this!

Thanks, I'm happy it got into PG10 too. Just to make it very clear - the current implementation is fairly simple, and may not be smart enough to deal with more complicated dependencies between columns. Hopefully that will be improved in PG11.
Post reply on HN