Postgres is awesome and thankfully is much easier to get set up with high availability and replication baked-in (remember pgpool anyone?). AWS Cloud Formation Docker Swarm stack + postgres primary/replica compose file + datadog and you're good to go.
PostgreSQL 10 Beta 1 Released
11–20 of 172 posts
Re: PostgreSQL 10 Beta 1 Released
#12The native table partitioning makes me so happy. I'd been doing this for years with really hacky external modules and tons of triggers. Sadly, even then there were always weird edge cases. Postgres really has become the most versatile database out there. I cringe whenever I have to work with MySQL again...
Every time I see a job post mentioning mysql I realize they just haven't discovered postgres, or they have some really gross problem. :/
Re: PostgreSQL 10 Beta 1 Released
#13While 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 single knob I wanted to be able to turn so many times in the past now (especially the n-distinct counts).
Most of the time, the planner does an ok job, but sometimes you have tables in a peculiar shape and if you're unlucky, the planner will opt into horribly bad plans. Whenever this happened for me, it was due to one of the two things CREATE STATISTICS allows me to tune in the future.
Thank you, thank you, thank you to whoever gave us this wonderful feature
Re: PostgreSQL 10 Beta 1 Released
#14The native table partitioning makes me so happy. I'd been doing this for years with really hacky external modules and tons of triggers. Sadly, even then there were always weird edge cases. Postgres really has become the most versatile database out there. I cringe whenever I have to work with MySQL again...
Every time I see a job post mentioning mysql I realize they just haven't discovered postgres, or they have some really gross problem. :/
Or they want to allow for case-insensitivity of some data, like for example email addresses on login forms.
As much as postgres is overall better than MySQL in so many ways, it's still ridiculously difficult to set things up such that
SELECT id FROM users WHERE email='foo@example.com'
SELECT id FROM users WHERE email='Foo@example.com'Re: PostgreSQL 10 Beta 1 Released
#15As someone with little to no Postgres experience, it seems like they are heading in the direction of providing the type of massively parallel, scale out features that Citus provides. Would love to hear thoughts from someone with real expertise.
Citus is building functionality on PostgreSQL to provide sharding for data sets too large for a single machine. There aren't really any PG 10 features that duplicate that. Some of the new PG features such as increased query parallelism allow for better utilization of single-machine resources. Other features such as logical replication may allow for some horizontal scaling by splitting read workloads across replicas,…
Many of them seem like pre-requisites however. I understand what Citus does vs Postgres. But that gap is narrowing.
Re: PostgreSQL 10 Beta 1 Released
#16Congratulations to the team. The replication/partition improvements are significant and much appreciated. My favorite improvements are full text search of JSON & JSONB; this makes pg a full replacement for Mongo for my use cases.
I feel like this feature replaces almost all of Mongo's use cases!
I'm interested. When you say almost, can you elaborate on any remaining use cases when you'd use Mongo?
Re: PostgreSQL 10 Beta 1 Released
#17Earlier quoted context omitted.
Every time I see a job post mentioning mysql I realize they just haven't discovered postgres, or they have some really gross problem. :/
Or they want to allow for case-insensitivity of some data, like for example email addresses on login forms. As much as postgres is overall better than MySQL in so many ways, it's still ridiculously difficult to set things up such that SELECT id FROM users WHERE email='foo@example.com' returns the same result as SELECT id FROM users WHERE email='Foo@example.com'
WHERE email ILIKE 'foo@example.com'
https://www.postgresql.org/docs/9.6/static/functions-matchin...
Re: PostgreSQL 10 Beta 1 Released
#18Earlier quoted context omitted.
Every time I see a job post mentioning mysql I realize they just haven't discovered postgres, or they have some really gross problem. :/
Or they want to allow for case-insensitivity of some data, like for example email addresses on login forms. As much as postgres is overall better than MySQL in so many ways, it's still ridiculously difficult to set things up such that SELECT id FROM users WHERE email='foo@example.com' returns the same result as SELECT id FROM users WHERE email='Foo@example.com'
Does MySQL do that on varchar by default?
Can't you just do this in PostgreSQL?
SELECT id FROM users WHERE email = lower('Foo@example.com')Re: PostgreSQL 10 Beta 1 Released
#19Earlier quoted context omitted.
Every time I see a job post mentioning mysql I realize they just haven't discovered postgres, or they have some really gross problem. :/
Or they want to allow for case-insensitivity of some data, like for example email addresses on login forms. As much as postgres is overall better than MySQL in so many ways, it's still ridiculously difficult to set things up such that SELECT id FROM users WHERE email='foo@example.com' returns the same result as SELECT id FROM users WHERE email='Foo@example.com'
Just lowercase everything. Not that hard.