Developers coming from SQL Server often approach PostgreSQL with the assumption that spatial functionality will look and behave more or less the same. After all, both systems expose geometry and geography types, both support distance calculations, and both offer spatial indexes. That assumption is only partially correct. While PostgreSQL with PostGIS covers everything SQL Server …
When SQL Server professionals start working seriously with PostgreSQL, most of the learning curve feels comfortable. Tables behave as expected, transactions are familiar, and B-tree indexes look reassuringly similar to what you have used for years in SQL Server. Then you encounter BRIN indexes. At first glance, they seem almost reckless: no row pointers, no …
If you come from SQL Server (like in my case), PostgreSQL indexing can feel familiar at first – B-tree indexes exist, composite indexes exist, covering indexes exist. And then you run into queries like this: or this: At that point, most SQL Server developers ask two questions: What are these operators? Why does PostgreSQL need …
When SQL Server developers begin working with PostgreSQL, indexing usually feels familiar at first. B-tree indexes behave as expected, query plans look readable, and the query planner makes reasonable choices. But PostgreSQL also introduces new index types like GiST and SP-GiST. They do not map cleanly to anything in SQL Server, and documentation often describes …
If you come from a SQL Server background (like in my case), you already have strong instincts about indexing. You know why B-trees dominate, why sorted structures matter, and why equality predicates are usually fast enough without special tricks. When you first encounter Hash Indexes in PostgreSQL, the obvious question is not how they work, …
Be sure to checkout the FREE SQLpassion Performance Tuning Training Plan – you get a weekly email packed with all the essential knowledge you need to know about performance tuning on SQL Server.
