PostGIS - en to ko_KR translation catalogue (16 entries)

note: Tag: title
en: Small tables of large geometries
ko_KR: 대용량 도형을 담은 저용량 테이블

note: Tag: title
en: Problem description
ko_KR: 문제점 설명

note: Tag: title
en: Workarounds
ko_KR: 해결 방법

note: Tag: para
en: The PostgreSQL people are trying to solve this issue by making the query estimation TOAST-aware. For now, here are two workarounds:
ko_KR: PostgreSQL 개발자들은 쿼리 추정이 TOAST를 인식하도록 만들어 이 문제를 해결하려 하고 있습니다. 현 시점에서는, 다음 두 가지 해결 방법이 있습니다:

note: Tag: para
en: The first workaround is to force the query planner to use the index. Send "SET enable_seqscan TO off;" to the server before issuing the query. This basically forces the query planner to avoid sequential scans whenever possible. So it uses the GIST index as usual. But this flag has to be set on every connection, and it causes the query planner to make misestimations in other cases, so you should "SET enable_seqscan TO on;" after the query.
ko_KR: 첫 번째 해결책은 쿼리 설계자가 인덱스를 사용하도록 강제하는 방법입니다. 쿼리를 전송하기 전에 서버로 "SET enable_seqscan TO off;"를 전송하십시오. 이렇게 하면 기본적으로 쿼리 설계자가 순차 스캔을 사용할 수 있는 경우에도 사용하지 않도록 강제합니다. 따라서 평상시처럼 GiST 인덱스를 이용할 것입니다. 그러나 이 플래그를 매번 연결할 때마다 설정해야 하고 다른 상황에서 쿼리 설계자가 잘못 추정하도록 하기 때문에, 쿼리가 끝난 후에 "SET enable_seqscan TO on;"을 전송해야 합니다.

note: Tag: para
en: The second workaround is to make the sequential scan as fast as the query planner thinks. This can be achieved by creating an additional column that "caches" the bbox, and matching against this. In our example, the commands are like:
ko_KR: 두 번째 해결책은 쿼리 설계자가 추정하는 만큼 순차 스캔 속도를 높이는 방법입니다. 경계 상자를 "캐시"하는 추가 열을 생성한 다음, 이 추가 열을 대상으로 일치 여부를 쿼리하면 됩니다. 이번 예제의 경우, 해당 명령어는 다음과 같습니다:

note: Tag: para
en: Now change your query to use the &amp;&amp; operator against bbox instead of geom_column, like:
ko_KR: 이제 geom_column 대신 bbox 에 대해 &amp;&amp; 연산자를 이용하도록 다음과 같이 사용자 쿼리를 변경하십시오:

note: Tag: para
en: Of course, if you change or add rows to mytable, you have to keep the bbox "in sync". The most transparent way to do this would be triggers, but you also can modify your application to keep the bbox column current or run the UPDATE query above after every modification.
ko_KR: 물론, mytable의 열을 변경하거나 추가할 경우, bbox의 "일관성"을 유지해야 합니다. 일관성을 유지시키는 가장 명료한 방법은 트리거(trigger)일 것입니다. 물론 사용자 응용 프로그램을 수정해서 bbox 열의 정보를 항상 최신 상태로 유지하도록 하거나, 모든 수정 작업 후 매번 앞에서 나온 UPDATE 쿼리를 실행할 수도 있습니다.

note: Tag: title
en: CLUSTERing on geometry indices
ko_KR: 도형 인덱스에 대한 클러스터 작업

note: Tag: para
en: For tables that are mostly read-only, and where a single index is used for the majority of queries, PostgreSQL offers the CLUSTER command. This command physically reorders all the data rows in the same order as the index criteria, yielding two performance advantages: First, for index range scans, the number of seeks on the data table is drastically reduced. Second, if your working set concentrates to some small intervals on the indices, you have a more efficient caching because the data rows are spread along fewer data pages. (Feel invited to read the CLUSTER command documentation from the PostgreSQL manual at this point.)
ko_KR: 레코드 대부분이 읽기 전용이고, 쿼리의 대다수가 단일 인덱스를 이용하는 테이블의 경우, PostgreSQL은 CLUSTER 명령어를 제공합니다. 이 명령어는 모든 데이터 행을 인덱스 기준과 동일한 순서로 물리적으로 재정렬합니다. 이렇게 하면 성능 향상 관련 두 가지 장점이 나타납니다. 첫째, 인덱스 범위 스캔을 하는 경우 데이터 테이블에 대한 요청 횟수가 극단적으로 줄어듭니다. 둘째, 사용자가 작업중인 집합이 인덱스 상의 조금 작은 간격에 집중하고 있을 경우 데이터 행이 더 적은 데이터 페이지를 따라 퍼져 있기 때문에 더 효율적인 캐시 작업이 가능합니다. (이 시점에서 PostgreSQL 지침서에 있는 CLUSTER 명령어 문서를 읽어보는 편이 좋습니다.)

note: Tag: para
en: However, currently PostgreSQL does not allow clustering on PostGIS GIST indices because GIST indices simply ignores NULL values, you get an error message like:
ko_KR: 하지만, 현재 PostgreSQL은 PostGIS GiST 인덱스에 대한 클러스터 작업을 허용하지 않습니다. 왜냐하면 GiST 인덱스가 NULL 값을 단순히 무시하기 때문에, 다음과 같은 오류 메시지를 보게 될 것입니다:

note: Tag: para
en: As the HINT message tells you, one can work around this deficiency by adding a "not null" constraint to the table:
ko_KR: HINT 메시지의 내용대로, 테이블에 "not null" 제약조건을 추가하면 이 결점을 피해 갈 수 있습니다:

note: Tag: para
en: Of course, this will not work if you in fact need NULL values in your geometry column. Additionally, you must use the above method to add the constraint, using a CHECK constraint like "ALTER TABLE blubb ADD CHECK (geometry is not null);" will not work.
ko_KR: 물론, 사용자 도형 열 안에 실제로 NULL 값이 필요한 경우 이 방법을 쓸 수는 없습니다. 또한 제약조건을 추가하려면 앞의 메소드를 이용해야 합니다. "ALTER TABLE blubb ADD CHECK (geometry is not null);"처럼 CHECK 제약조건을 사용하는 방법은 먹히지 않을 겁니다.

note: Tag: title
en: Avoiding dimension conversion
ko_KR: 차원 변환 피하기

note: Tag: para
en: Sometimes, you happen to have 3D or 4D data in your table, but always access it using OpenGIS compliant ST_AsText() or ST_AsBinary() functions that only output 2D geometries. They do this by internally calling the ST_Force2D() function, which introduces a significant overhead for large geometries. To avoid this overhead, it may be feasible to pre-drop those additional dimensions once and forever:
ko_KR: 때때로 사용자 테이블에 3D 또는 4D 데이터가 있지만, 항상 2D 도형만을 출력하는 OpenGIS 준수 ST_AsText() 또는 ST_AsBinary() 함수를 통해서만 접근하는 경우가 있을 수 있습니다. 이런 경우 내부적으로 ST_Force2D() 함수를 호출하는데, 대용량 도형의 경우 이 함수는 시스템의 자원을 상당히 잡아먹습니다. 이런 자원 낭비를 피하려면, 미리 그 추가적인 차원을 완전히 삭제하는 편이 효율적일 수 있습니다.

note: Tag: para
en: Note that if you added your geometry column using AddGeometryColumn() there'll be a constraint on geometry dimension. To bypass it you will need to drop the constraint. Remember to update the entry in the geometry_columns table and recreate the constraint afterwards.
ko_KR: AddGeometryColumn() 함수를 통해 사용자 도형 열을 추가했을 경우 도형 차원에 제약조건이 걸려 있다는 사실을 주의하십시오. 이를 우회하려면 제약조건을 삭제해야 합니다. geometry_columns 테이블 내부 항목을 업데이트한 다음 제약조건을 다시 생성하는 걸 잊지 마십시오.
