나는 행 단위로 사용자 정의 함수를 미리 계산하려고합니다. 아이디어는 필드 중 하나에서 JSON 개체를 텍스트 개체로 사용하고 다른 실제 필드와 마찬가지로 쿼리에서 반환 할 수있는 다른 '필드'를 구문 분석하려고합니다. 그러나 JSON 구문 분석의 오버 헤드가 중요합니다. 쿼리 속도를 향상시키는 방식으로이 구문 분석 함수를 미리 계산할 수있는 방법이 있습니까?precomputing postgresql의 사용자 정의 함수
처음에는 데이터베이스에 JSON을 텍스트로해서는 안된다고 주장하지 마십시오. 나는 장단점을 알고있다.
먼저, 곧 출시 될 PostgreSQL 9.2의 JSON data type에 관심이있을 수 있습니다.
질문에 대해서는 구체화보기 (또는 더 간단한 양식 : 테이블의 중복 된 미리 계산 된 열)을 찾고 있습니다. "구체화 된보기"는 PostgreSQL 데이터베이스의 특수한 객체가 아니라 기존 용어입니다. 기본적으로 미리 계산 된 값을 가진 중복 테이블을 만들고 특정 이벤트 또는 적시에 새로 고칩니다.
search for the term 몇 가지 답변을드립니다. 이것은 UDF는 불변의 의미 출력으로 표시되는 경우에만 작동
CREATE INDEX my_foo_bar_udf_idx ON foo (bar(baz));
:
그러나 미리 계산 된 열 대신 사전 계산 된 쿼리를 제공하지 않습니까? – ferson2020
@StevenMcPherson : 죄송합니다. 따라 가지 않습니다. "이것"은 무엇입니까? –
구체화 된보기 사용. 그것에 대해 조금 읽은 후 그것을 이해하면 쿼리를 미리 계산하여 테이블에 저장한다는 것입니다. 중복 테이블에 행당 값을 저장할 수 있어야합니다. – ferson2020
구체화 된 뷰뿐만 아니라, PostgreSQL을 또한 인덱스 기능 '출력 그래서 당신이 뭔가를 할 수 있습니다 것을 명심 인수에만 의존합니다. 이렇게하면 쿼리 인수에 대해 함수를 실행 한 다음 테이블 대신 인덱스를 스캔 할 수있는 옵션이 제공됩니다. 모든 유스 케이스를 충족시키지는 못하지만 대부분의 경우를 충족 시키므로 종종 뷰를 구체화하는 두통을 덜어줍니다.
거의 데이터가 ETL 프로세스 (변환로드 추출)를 설정하려는 것처럼 느껴집니다. 야간에 실행되는 ETL 도구 (또는 일련의 스크립트)에 JSON 필드를 읽고 좀 더 데이터베이스 친화적 인 것으로 변환하는 것에 반대합니까? – Twelfth