Live data from Hacker News

Why people care about PostGIS and Postgres

pathtocituscon.transistor.fm

41–42 of 42 posts

Re: Why people care about PostGIS and Postgres

#41
post #8

Earlier quoted context omitted.

Sequel Pro is the one I keep comparing all Postgres clients to. Beekeper is nice but lacks some of the GUI Tools, there's no point in having a nice GUI but not any good amount of functionality. At times I see folks new to Postgres using 2 or 3 different GUIs to do different things.

sequel pro (which afaik has not been updated since 1928?) could be compared with postico2 as far as native look and feel go - https://eggerapps.at/postico2/ never realized sequel pro was open source: https://github.com/sequelpro/sequelpro

Yup, it’s crazy something unmaintained is still such a noticeably better experience than any of the Postgres clients I have seen.

The note about sequel ace below is worth noting too for anyone wanting to try it out.

Re: Why people care about PostGIS and Postgres

#42
post #34

Earlier quoted context omitted.

That isn't my experience at all. MySQL wins at serving a large number of very simple SELECT queries and plain bulk INSERTs. But Postgres wins hands down once the queries get slightly more complex, for larger numbers of concurrent UPDATEs, and kicks the pants off MySQL with a RETURNING clause where you don't have to perform a followup SELECT after each write, especially to get the new ID. (Necessary for writable CTEs…

Can’t speak to your experience or schema, but IME MySQL does just fine at high (100+K QPS) mixed workload, with complicated queries. It does require more tuning than Postgres, but OTOH there’s more to monitor to determine exactly what is bottlenecking. That’s certainly not to say Postgres can’t also handle volume, but its MVCC design and O2N tuple ordering doesn’t lend itself as easily to high write workloads. No ret…

> Similarly, yes, functional indices are quite nice if you know how and when to use them.

In fairness to MySQL, you can simulate this surprisingly well by adding indexes to computed columns.

> I’d love to see benchmarks comparing the two RDBMS, properly tuned, with the same workload. I’m OOO this week but I might do that in the future to see for myself.

This is where I see most existing database benchmarks falling down.

tl;dr: testing database performance across engines is a lot harder than most folks realize.

Imagine you have a DB where you're tracking classroom assignments for all public schools in the state. Here are some requirements:

* A classroom must have at least one teacher and at least one student per class scheduled.

* A classroom must not allow more students than its capacity.

* No teacher or student may be assigned to more than one classroom at the same day/time.

To solve this in MySQL, you MUST use application code to check for conflicts and will always be subject to race conditions at your data layer.

The check for existing slots must always be a separate query from the insert, and MySQL cannot restrict overlapping timestamp ranges at the data layer. This requires data custodial work to resolve.

Postgres on the other hand both supports a timestamp range type but also allows exclusion constraints to prevent the same person from being assigned to more than one class when those ranges overlap—a data layer restriction that makes app support code unnecessary and race conditions logically impossible.

Testing "the same workload" is difficult because the data schemas do not match, the application code calling it will not match, and if you did implement it, folks would cry about "apples and oranges" and how they're not the same workload.

In MSSQL, you might write a .NET component that lives in the database and handles the potential race condition. You also might use temporal tables in that engine to track changes over time, something that (again) would involve non-trivial code changes for MySQL and Postgres to match requirements.

Post reply on HN