https://jomuljomul.tistory.com/m/entry/PostgreSQL-%EA%B3%B5%EB%B6%80%ED%95%98%EA%B8%B0-PostgreSQL-Index%EB%8A%94-B-Tree%EB%A5%BC-%EC%96%B4%EB%96%BB%EA%B2%8C-%EC%82%AC%EC%9A%A9%ED%95%A0%EA%B9%8C

btree 와 b+tree 구분을 각 노드에 키 중북이 있는가로 구분한다면 b+tree 입니다.

크게 보면 의미 없어요.

그냥 범위 검색을 할 때는 btree 인덱스를 쓴다.

뭐 단일 키 검색 (= 연산 검색)에서도 hash랑 엄청난

차이가 있으니 반드시 hash 인덱스를 쓰는게 좋다는 것도 아니니

그냥 인덱스는 btree 기본 형태를 쓴다. 

정도로만 알고 있으면 됩니다.

더 중요한 것은 어떤 퀴리의 작업 비용을 최적화 하기위해

어떤 자료형을 쓸 것이고,

어뗜 칼럼 기준으로 인덱스를 만들어 둘 것인가,

이 계획이 자료가 많아지는 상황에서도 유효한가를 

고민하는 것입니다.

저도 더 중요한 것은 어떤 상황에서 어떤 자료구조와 인덱스를 사용하는 것을 고민하는 것이라고 생각하고, 그 부분을 좀 더 중점적으로 공부하고 있습니다.

다만, 거대한 프로덕트에서 여러 선택지 중 하나를 사용할 때는 깊은 고찰과 연구가 있을 것이라고 생각했고, 그 이유가 궁금해서 질문 남겼습니다.

질문의 요지가 PostgreSQL은 b+tree 인덱스를 왜 사용했는가?

이거인거죠?

이걸 이해하려면, b+tree 인덱스의 등장 배경을 이해해야합니다.

인터넷에서 이렇게 소개하네요.

https://velog.io/@bambookim/B-Tree-BTree

--------

B+Tree

B-Tree는 어떤 한 데이터의 검색에서는 빠를 수 있으나, 모든 데이터를 순회하기 위해서는 leaf node까지 갔다가 다시 부모 node로 BackTracking하여 트리의 모든 node를 방문해야 하므로 비효율적이다. 이러한 단점을 보완한 것이 B+Tree이다.

--------

즉, between 연산 최적화를 위해서는 btree 로는 부족했던거죠.

속도를 얻고, 인덱스 key 중복 저장을 허용하는 것을 취한거죠.

이거 말고 다른 이유가 있을까싶네요.

자료처리에서 현재 기술 이론상으로는 between 연산에서 b+tree 만한 놈이 아직 없어,

다들 이거 씁니다.

그래서, RDBMS에서 btree 이러면, b+tree를 암묵적으로 지시하는게 일반적입니다.

요즘 데이터베이스 가운데, 전통 btree 인덱스를 쓰는 데이터베이스를 저는 모릅니다. 제가 알고 있는 데이터베이스는 모두 b+tree 입니다.