21–30 of 87 posts
Ran into a pathological case where a query that usually took 10-20ms would sometimes, semi-randomly, take > 15 minutes (while the corresponding PG process server-side is running at 100% CPU)
Explain showed a dramatic query plan change, which led us towards bad table statistics.
I would love to drop MySQL/MariaDB and go with PostgreSQL, but information like this makes me nervous that I would setup a footgun and be constantly debugging things because I am not a DB admin expert. Anyone care to comment on how PostgreSQL works out of the box without being an expert? (I've run MySQL/MariaDB for almost 20 years and there are very few issues I've been surprised by)
Optimizations as presented by many are not needed right up front and you'll learn them as you go along. Good luck!
Obviously I love learning new things, but I've just never felt inclined to try it out, whereas I'm always jumping between other languages and frameworks within them. Not sure why that is.
Additionally, the linked article about checking for unused indexes is really helpful IMO.
https://blog.crunchydata.com/blog/cleaning-up-your-postgres-...
As someone who's used MySQL for 17 years and dabbled a little in Mongo is there any reason to try and switch to Postgres? Obviously I love learning new things, but I've just never felt inclined to try it out, whereas I'm always jumping between other languages and frameworks within them. Not sure why that is.
You don’t realize how limited you are until you really get into all the additional capabilities that PG brings…and then have them unavailable.
I would have said, check your shared buffers memory and concurrency are configured right for the environment you are running on. The defaults are wrong for most production environments and the right values are highly server dependent. If you haven't specifically tuned them for your production server, chances are they are wrong and you are leaving substantial memory and / or concurrency on the table.
How would one go about determining the right values for these settings?
https://blog.crunchydata.com/blog/optimize-postgresql-server...
As someone who's used MySQL for 17 years and dabbled a little in Mongo is there any reason to try and switch to Postgres? Obviously I love learning new things, but I've just never felt inclined to try it out, whereas I'm always jumping between other languages and frameworks within them. Not sure why that is.
MySQL clustering and operations tooling seems much better. No vacuums to worry about
As someone who's used MySQL for 17 years and dabbled a little in Mongo is there any reason to try and switch to Postgres? Obviously I love learning new things, but I've just never felt inclined to try it out, whereas I'm always jumping between other languages and frameworks within them. Not sure why that is.
> MySQL is a pretty poor database, and you should strongly consider using Postgres instead.
https://web.archive.org/web/20220104181634/https://blog.sess...
Earlier quoted context omitted.
I read this as "maybe a few (which are the ones automatically created on primary keys)", as opposed to redundant indices created on primary keys.
I would agree IFF there wasn't the 'maybe'. If that word wasn't there I would read it as having not many tables in the beginning and thus not many primary keys and thus not many primary key indices. 'maybe' changes that dramatically unfortunately.
Does this mean PGbouncer is unnecessary for postgres > v14?