111–120 of 147 posts
Someone who picked their tools with good tech judgement 25 years ago can be using the same today (eg PG, Python, Linux) without corporate control of them, it's pretty great.
25 years ago... PostgreSQL 6, Python 1.5, Linux 2.2? I don't know if picking those tools was good judgement then...
Earlier quoted context omitted.
That feels a bit like hindsight talking. Linux perhaps, but were Python and Postgres really the obvious good judgement choices 25 years ago? Every other choice was poor judgement?
Well 25 years ago was pretty much (December 1998) when "LAMP"[1] was defined and that was originally Linux, Apache, MySQL and PHP. So Postgres and Python were not the obvious choices back then. [1] https://en.wikipedia.org/wiki/LAMP_(software_bundle)
Earlier quoted context omitted.
That's true for the kernel, How about extensions such as ParadeDB BM25 https://www.paradedb.com/ + PGroonga https://pgroonga.github.io/ + PG Bigm https://github.com/pgbigm/pg_bigm ?
also with pg_trgm[0] (mentioned by OP) and pgvector for semantic search you have a pretty powerful search toolkit. for example, combining them for Hybrid Search [1] [0] https://www.postgresql.org/docs/current/pgtrgm.html [1] Reciprocal Ranked Fusion: https://supabase.com/docs/guides/ai/hybrid-search
Earlier quoted context omitted.
> 99% of people who recommend or use Postgres barely know how to use it. You're not wrong here, although you could just as easily say "99% of people who recommend $DB barely know how to use it." Databases remain a mysterious black box to entirely too many people, despite the three largest (SQLite, Postgres, MySQL) being open source, and having extensive documentation. I've come to the conclusion that most devs don't…
I feel this on a soul level. I wrote about it: https://renegadeotter.com/2023/11/12/your-database-skills-ar...
Alright I'm convinced, I'm using postgres for my next project. Anyone have any experiences with it and Entity Framework Core?
Earlier quoted context omitted.
No this is a fundamental concept in postgres. If you do EXPLAIN ANALYZE on a query, you get the query plan, which is influenced by the query, indexes, table structure, etc. But the QP may decide to do a silly thing like a sequential scan where a better path exists, and adding an index to avoid the scan would be cost prohibitive. So if you could just override the QP and say "Use this index and do this type of sort and…
Nobody does actually. Postgres not having deterministic query plans is a big pain and a good reason not to use it. The same query may use different query plans depending on the estimated number of affected rows, very frustrating.
Postgresql doesn't have this, however, I've rarely missed this feature - tables with good indexes, regular db hygiene, etc, almost always perform excellently. The query planner is very, very smart nowadays.
Postgres is far from perfect: - The codebase is old and huge, accruing some heavy technical debt, making it a less than ideal foundation for iterating quickly on a new paradigm like AI and vector databases. - Some ancient design decisions have aged poorly, such as its one connection per process model, which is not as efficient as distributing async tasks over thread pools. If not mitigated through an external connect…
they have several ways to write extensions: extensions and fdw, so you can build your cool AI stuff without digging into PgSQL sources much.
Earlier quoted context omitted.
That feels a bit like hindsight talking. Linux perhaps, but were Python and Postgres really the obvious good judgement choices 25 years ago? Every other choice was poor judgement?
Well 25 years ago was pretty much (December 1998) when "LAMP"[1] was defined and that was originally Linux, Apache, MySQL and PHP. So Postgres and Python were not the obvious choices back then. [1] https://en.wikipedia.org/wiki/LAMP_(software_bundle)
Earlier quoted context omitted.
No this is a fundamental concept in postgres. If you do EXPLAIN ANALYZE on a query, you get the query plan, which is influenced by the query, indexes, table structure, etc. But the QP may decide to do a silly thing like a sequential scan where a better path exists, and adding an index to avoid the scan would be cost prohibitive. So if you could just override the QP and say "Use this index and do this type of sort and…
Nobody does actually. Postgres not having deterministic query plans is a big pain and a good reason not to use it. The same query may use different query plans depending on the estimated number of affected rows, very frustrating.
As a user, postgres is a far more ergonomic database, but things like this show good old insane oracle is still strongly ahead on some of these points.
In practice, postgres is not as bad as you'd expect in the large, but it can still be anoying.
Someone who picked their tools with good tech judgement 25 years ago can be using the same today (eg PG, Python, Linux) without corporate control of them, it's pretty great.
That feels a bit like hindsight talking. Linux perhaps, but were Python and Postgres really the obvious good judgement choices 25 years ago? Every other choice was poor judgement?
Despite me not knowing much about databases it seemed like an obvious choice.