작성자임. pgrust에서 현재 최우선 순위는 정확성이며, 지난 2주간 형식 검증과 차등 퍼즈 테스트를 병행했음
사용자 대상 함수 1,000개 이상이 pgrust와 Postgres에서 정확히 같은 논리로 동작함을 증명했고, 형식 검증이 어려운 함수는 C와 Rust 구현에 수백만 개 입력을 넣어 결과가 항상 같은지 확인했음
아직 전체 표면적의 약 15%만 다뤘지만 pgrust에서 약 100개, Postgres 자체에서 약 20개의 버그를 발견함. 특히 Postgres의 사분 트리 구현에서는 부동소수점 반올림 때문에 어떤 점이 중심점보다 위도 아래도 같지도 않은 상태가 될 수 있었음(관련 버그) Antithesis와 Jepsen 방식의 장애 테스트를, Aretta와 더 본격적인 형식 검증을 진행 중임. 프로젝트를 지원하려면 GitHub 저장소에 별을 눌러주면 됨

올바른 성능 최적화인지 어떻게 판단하는지 궁금함. Marginalia 색인에서는 운영 프로파일러로 병목 메서드를 찾아도, 여러 겹의 캐시 때문에 테스트 장비에서 같은 특성을 재현하기 어려움
테스트에서는 크게 빨라져도 운영 프로파일러 수치가 움직이는 경우는 일부뿐임. 최근에는 mincore 검사 결과에 따라 유사 인접 데이터를 읽을 때 mmap과 io_uring을 전환하는 혼합 방식을 시험 중인데, 테스트와 운영 모두 실질적인 이득은 있어도 개선 폭 수치는 전혀 일치하지 않음

부동소수점 비교 버그는 몇 년을 들여다봐도 실수를 찾지 못할 만큼 끔찍해 보임

운영 데이터베이스의 WAL을 실시간 추적하는 읽기 전용 분석 복제본으로 쓰기에는 아직 준비됐는지 궁금함

PostgreSQL에서 20초가 걸렸다는 측정에는 디스크 읽기가 반영되지 않은 듯함. 집계 질의라면 먼저 디스크에서 데이터를 읽어야 하는데, 테이블이 이미 메모리에 있다고 가정한 것인지 궁금함
Rust 버전은 명백히 메모리상에서 처리하는 듯하지만, 생성자라면 꼭 그렇지 않을 수도 있음

pg → peerdb → ClickHouse 복제본을 거쳐, 지금은 pg → pg_clickhouse 확장을 설치한 다른 pg → ClickHouse 구조를 사용 중임
분석 질의는 연결 포트만 바꾸면서 동일한 PostgreSQL 문법을 유지할 수 있음. pg_clickhouse에 PR 3개를 보냈고 1개가 병합됐으며, 그 외에는 꽤 잘 작동함. pgrust가 더 쉽고 잘 동작한다면 대안으로 검토할 의향이 있음

pgrust가 기술적으로 더 뛰어나고 빨라지더라도 향후 5~10년 내 사람들이 일반적으로 Postgres 대신 선택할 가능성은 낮아 보임. 핵심 기술에는 개발 속도나 성능뿐 아니라 신뢰받는 Postgres 팀, 장기 존속성과 연속성도 필요함

경쟁 가능성과 이미 존재하는 개념 증명이 Postgres 팀에 기존에는 추진하지 않았을 성능 개선 동기를 줄 수 있음

실제 이득을 제공하고 PostgreSQL이 풀지 못하는 문제를 해결한다면 채택될 것임

사실상 바이브 코딩으로 만들어졌다는 점도 있음

기존 도구로 원하는 일을 할 수 없으면 새로운 기술도 기꺼이 도입함. 실제로는 신뢰성 우려보다 Postgres를 선호하는 교조주의가 더 강하게 작용하곤 함
구체적인 용도로 직접 시험하고 각 데이터베이스를 충분히 이해해야 합리적으로 결정할 수 있지만, 조직에 그런 사람이 없거나 있어도 의사결정권이 부족할 가능성이 큼

장기 존속성과 연속성 때문에 여전히 COBOL과 메인프레임을 쓰는 회사도 있음. Postgres와 pgrust가 함께 성장하지 못할 이유는 없으며 용도에 따라 선택하면 됨

1~2주 전 자체 벤치마크로 pgrust를 시험했는데 여러 차례 충돌했음. 현재로서는 신뢰하기 어려움

ScyllaDB의 설명 같은 I/O 스케줄러 구조와 스레드 스케줄러에 대한 상세 문서가 필요함
PostgreSQL은 전통적으로 시끄러운 이웃 문제를 잘 관리하지 못했지만 스레드 풀과 I/O 우선순위로 해결할 수 있는데, pgrust가 이를 다뤘는지 궁금함

스케줄러는 이 논문과 논문을 크게 참고했으며 두 문제를 해결함
첫째, 자원 집약적 질의를 제한할 수 있음. 둘째, 작업 훔치기를 지원해 유휴 CPU 코어를 실행 중인 질의에 배정함. 장비 자원이 필요 이상으로 넉넉하다면 남는 용량으로 질의를 가속함

적응형 계획을 오랫동안 기다려 왔음. 여러 운영 데이터베이스에서 이미 검증된 기법인데도 Postgres 코어 팀이 구현을 꺼려온 점이 큰 불만이었음
적어도 이 프로젝트가 학술·틈새 영역 밖에서도 해당 모델이 실용적임을 입증하길 바람

일괄 처리 최적화 방식을 보면, 단순화를 위해 세부 사항을 생략한 게 아니라면 윈도 함수 구현에서 문제가 생길 가능성이 있어 보임

이미 k나 kdb처럼 이것보다 몇 자릿수나 빠른 대안이 있는데 왜 필요한지 이해하기 어려움
Postgres는 자신이 다루는 규모와 문제에서 훌륭함. 원시 속도가 핵심인 극도로 중요한 페타스케일 시스템이라면, 오히려 문제에 맞지 않는 해법을 억지로 적용하는 셈일 수 있음

느린 것보다 빠른 것이 낫고, Postgres는 훌륭함. SQLite를 쓸 때는 더 나은 데이터 마이그레이션과 동시성 같은 장점이 그리워짐
올바른 색인이 있어도 질의 비용은 공짜가 아니며 기대보다 느릴 수 있음. OLAP형 질의에 Postgres를 쓰지 말라고 할 수도 있지만, 가능하다면 데이터베이스 두 개 대신 하나만 사용하고 선호하는 데이터베이스를 더 많은 곳에 적용하는 편이 나음

시험하려 했지만 ERROR: convert_string_datum (selfuncs.c): pg_strxfrm leg; C-collation lane only와 thread 'pg:backend:1572' (11650) panicked at crates/backend/optimizer/plan/planner/src/selfuncs.rs:966:9: 오류가 발생했음. 아직 사용 준비가 되지 않은 상태로 판단함

AI라면 제목도 더 명확하게 쓸 수 있었을 것임. 수백만 명이 수십 년간 운영 환경에서 사용하고 지원 생태계, 서적, 컨설턴트, 관리형 호스팅 업체까지 갖춘 공식 PostgreSQL과 부분 호환 재구현은 분명히 구별해야 함