我正在使用postgresql-hstore扩展，并好奇数据是如何在内部存储的。请指出我可以在hstore源代码中查看实现细节的地方。
hstore是PostgreSQL主要发行版的一部分http://git.postgresql.org/和GitHub。这是用数字头表示的hstore。
它看起来像是作为varlena存储的，这意味着它和其他任何东西一样都是可伸缩的。缺点是需要从磁盘读取整个字段——至少在压缩的情况下是这样——才能提取密钥。
这也意味着，与任何其他正常字段值一样，更新字段的任何部分需要将整个元组(行)的新副本写入表，并在任何活动事务不再可见时将旧副本标记为过期(请参阅Pg手册中的MVCC)。因此，对于将频繁更改的数据来说，大的hstore是不可取的，因为每当它的任何部分发生更改时，都需要重写整个内容(以及包含它的行)。
hstore.hhstore_io.c
这些来源似乎没有包含太多评论来概述存储值的结构和存储方式，而且这有点像一个需要快速接受的宏森林。
存储本身并不令人意外。
有趣的部分是如何对其进行索引，以便能够有效地回答等查询
从planet_osm_line中选择osm_id，name，tags，其中'频率=>16.7，铁路=>"铁路"'<@标签；
(这来自一个真实的例子)意思是："查找(hstore)字段"包含"映射频率=>16.7和铁路=>铁路"的所有记录。
CAVEAT：这只是记忆。
有两个组成部分：
首先是GiST索引，它可以被视为一种"草率的B树"，有时它不会确切地告诉你应该选择哪个分支，而是给你一些分支。PostgreSQL将其用于几何索引(例如，可以查询点是否在多边形中)。该索引不会给你带来完美的效果，但可能会大大减少搜索空间。
其次，还有一种"hash"(对于Perlists)/"dictionary"(对于Pythonist)的编码，以利用GiST：您将哈希的每个键和每个键/值对散列为一个小int(细节很模糊，但我们假设0..255)，取一个这样大小的比特域，为你得到的每一个哈希值在比特域中戳一个洞(我认为Knuth有一个很好的例子，索引卡的边缘和编织针上都有开/闭的洞——是的，就在这里。
那你只要嫁给那两个就行了。AFAIR Oleg Bartunov和Theodor Tsigaev想出了这个主意。我第一次看到它的时候脑袋就爆炸了。