【发布时间】：2012-04-04 17:53:30
【问题描述】：
我是 PostgreSQL 的新手，尤其是它的性能调优方面。基本上，我们通过查询 3 个整数值来访问数据：segmentSize（范围 1...10）、segmentX（范围 +/- 100,000）、segmentY（范围 +/- 100,000）。
前瞻性考虑：当数据量增长时，可以将数据分成多个表，每个单独的 segmentSize 和/或 segmentX 和 segmentY 的连续范围。
目前的选择：我有一个架构选择，要么直接使用密钥（segmentSize、segmentX、segmentY），要么——为了获得性能——在 PostgreSQL 之外创建一个合成密钥，将segmentX、segmentY 组合成一个整数值这成为关键（或者不太可能，所有三个（segmentSize、segmentX、segmentY）。
问题：假设我们不太关心从segmentX，segmentY在Postgress之外发生的这种“组合密钥”派生的成本，并且考虑到我们并没有特别关注每行字节顺序的空间节省数据（除非它产生性能差异）， .... 与查询 segmentX 和 segmentY 的两个单独 int 值的组合相比，查询范围 segmentX * segmentY 的单个 int 值是否会带来任何可衡量或有意义的性能提升？
非常感谢。请随意添加任何扩展适用数据和索引策略的链接，以最大限度地提高 SELECT/读取性能。
【问题讨论】：
-
对您的查询使用 EXPLAIN 和 EXPLAIN ANALYZE 来查看和衡量正在发生的事情以及最有效的方法。
-
第一：什么是自然主键？第二：您的典型用法是什么：对 X 或 Y 或 {X,Y} 或 {Y,X} 的范围查询？第三：查询中的keyfields集合与“自然”PK的keyfields集合是否不同？它与插入操作中的键域集不同吗？第四：来自三个关键字段的集合：任何可能的对是候选键吗？第五：请添加对keyfields含义的描述。 “segment_id”对我们大多数人来说信息量不是很大。
-
@wildplasser 伟大的洞察力 - 谢谢。基本上，我们有一个类似于纽约曼哈顿城市街区的网格，其中街道（1 号到 11 号）和街道（1 号到 160 号）都有编号。因此，您可以将某些餐厅称为“靠近第 7 大道和第 34 街的拐角处”，就像人们在现实生活中所做的那样。或者，您可以遵循东京方案，其中每个街区都有一个编号，因此您可以将某些餐厅称为“街区 926”。在前一种情况下，我们有一个 (7,34) 的组合索引/键，在后一种情况下，一个键 926（因此来自更大的一组值）。
标签： sql performance postgresql indexing