未调用geometry字段的含geometry PostGIS表查询是否比无geometry表耗时更长？

geometry字段的存在确实会在特定场景下拖慢不涉及几何查询的速度，拆分为一对一关联在多数常规查询场景下能提升性能，但也存在例外情况，具体逻辑和建议如下：

• PostgreSQL的行存储逻辑中，大尺寸字段（比如包含大量节点的multipolygon，单个几何数据可能占几千到上万字节）会拉宽每行数据的整体宽度，导致单个磁盘数据页能存储的行数大幅减少。当你执行全表扫描、或者不走覆盖索引的过滤查询时，需要读取的磁盘页数量会明显上升，查询速度自然会变慢。
• 如果你的查询逻辑明确指定了不需要读取geometry字段，比如在GeoDjango中使用only()、defer()方法排除该字段，或是用values()/values_list()仅拉取需要的业务字段，PostgreSQL并不会读取geometry字段的实际存储内容，这种场景下是否拆分表对查询性能的影响极小，可以忽略。
• 拆分为一对一关联的优势：日常不需要几何字段的查询只需访问主表，主表行宽窄、数据页存储密度高，无论是索引扫描还是全表扫描的性能都更好，也无需每次查询都手动编写排除geometry字段的代码，降低业务代码的出错概率。
• 拆分为一对一关联的劣势：当你需要同时查询普通业务字段和几何字段时，需要多执行一次表关联操作，虽然4.5万行的量级下关联开销非常低，但如果是高频同时拉取两类数据的场景，性能反而会比单表存储稍差。

优化建议：如果90%以上的表查询都不需要用到geometry字段，优先选择拆分一对一关联；如果两类查询占比相近，或是几何查询属于业务高频场景，建议保留单表结构，仅在不需要几何字段的查询中主动用Django查询方法排除该字段即可，4.5万行的数据量下两种方案的性能差异不会特别悬殊，无需过度优化。

内容的提问来源于stack exchange，提问作者Terry