Overview

Project website postgis.net
Translation process
  • Translations can be made directly.
  • Translation suggestions can be made.
  • Any authenticated user can contribute.
  • The translation uses bilingual files.
Source code repository https://git.osgeo.org/gitea/postgis/postgis.git
Repository branch stable-3.2
Last remote commit Push to 3.2.6dev milestone 6e2c5206d
Regina Obe authored yesterday
Weblate repository https://weblate.osgeo.org/git/postgis_branch_32/postgis/
File mask doc/po/*/performance_tips.xml.po
Translation file Download doc/po/ja/performance_tips.xml.po
Last change None
Last author None

String statistics

Strings percent Hosted strings Words percent Hosted words Characters percent Hosted characters
Total 28 935 6,108
Translated 71% 20 73% 689 71% 4,391
Needs editing 28% 8 26% 246 28% 1,717
Read-only 0% 0 0% 0 0% 0
Failing checks 14% 4 18% 176 22% 1,379
Strings with suggestions 28% 8 26% 246 28% 1,717
Untranslated strings 0% 0 0% 0 0% 0
Last 12 months Previous

Activity in last 12 months

0 changes 30 changes 0 changes 0 changes 0 changes 0 changes 0 changes 0 changes 0 changes 8 changes 0 changes 0 changes 0 changes 0 changes 0 changes 0 changes 0 changes 0 changes 0 changes 0 changes 0 changes 0 changes 0 changes 0 changes
May Jun Jul Aug Sep Oct Nov Dec Jan Feb Mar Apr

Quick numbers

935
Hosted words
28
Hosted strings
71%
Translated
0
Contributors
and previous 30 days

Trends of last 30 days

—
Hosted words
—
—
Hosted strings
—
—
Translated
—
—
Contributors
—
User avatar anonymous

Suggestion added

postgis_branch_32 / performance_tips — Japanese

In case of large tables, it may be wise to divide this UPDATE into smaller portions by constraining the UPDATE to a part of the table via a WHERE clause and your primary key or another feasible criteria, and running a simple "VACUUM;" between your UPDATEs. This drastically reduces the need for temporary disk space. Additionally, if you have mixed dimension geometries, restricting the UPDATE by "WHERE dimension(geom)>2" skips re-writing of geometries that already are in 2D.
大きなテーブルの場合、WHERE節、およびプライマリキー若しくは他の適切な基準によってテーブルの一部へのUPDATEを制限させて、UPDATEの実行の間に単に"VACUUM;"と実行することで、UPDATEをより小さい塊に分割するのが賢いやり方かもしれません。これにより、テンポラリディスクスペースが劇的に減少します。さらに、次元混合のジオメトリを持つ場合、"WHERE dimension(the_geom)>2"によってUPDATEを制限することで、2次元で書かれているジオメトリの再書き込みをスキップさせることができます。
8 months ago
User avatar anonymous

Suggestion added

postgis_branch_32 / performance_tips — Japanese

UPDATE mytable SET geom = ST_Force2D(geom);
VACUUM FULL ANALYZE mytable;
UPDATE mytable SET the_geom = ST_Force2D(the_geom);
VACUUM FULL ANALYZE mytable;
8 months ago
User avatar anonymous

Suggestion added

postgis_branch_32 / performance_tips — Japanese

lwgeom=# ALTER TABLE my_table ALTER COLUMN geom SET not null;
ALTER TABLE
lwgeom=# ALTER TABLE my_table ALTER COLUMN the_geom SET not null;
ALTER TABLE
8 months ago
User avatar anonymous

Suggestion added

postgis_branch_32 / performance_tips — Japanese

lwgeom=# CLUSTER my_geom_index ON my_table;
ERROR: cannot cluster when index access method does not handle null values
HINT: You may be able to work around this by marking column "geom" NOT NULL.
lwgeom=# CLUSTER my_geom_index ON my_table;
ERROR: cannot cluster when index access method does not handle null values
(エラー: インデクスアクセスメソッドがNULL値を扱わない場合クラスタ化できません)
HINT: You may be able to work around this by marking column "the_geom" NOT NULL.
(ヒント: 列"the_geom"をNOT NULLとすることで、これを回避できるかもしれません)
8 months ago
User avatar anonymous

Suggestion added

postgis_branch_32 / performance_tips — Japanese

SELECT AddGeometryColumn('myschema','mytable','bbox','4326','GEOMETRY','2');
UPDATE mytable SET bbox = ST_Envelope(ST_Force2D(geom));
SELECT AddGeometryColumn('myschema','mytable','bbox','4326','GEOMETRY','2');
UPDATE mytable SET bbox = ST_Envelope(ST_Force2D(the_geom));
8 months ago
User avatar anonymous

Suggestion added

postgis_branch_32 / performance_tips — Japanese

To see whether your suffer from this issue, use the "EXPLAIN ANALYZE" postgresql command. For more information and the technical details, you can read the thread on the PostgreSQL performance mailing list: <ulink url="http://archives.postgresql.org/pgsql-performance/2005-02/msg00030.php">http://archives.postgresql.org/pgsql-performance/2005-02/msg00030.php</ulink>
この問題に苦しむかどうかを見るには、PostgreSQLの"EXPLAIN ANALYZE"コマンドを使います。詳細情報と技術情報については、PostgreSQL性能メーリングリストのスレッド<ulink url="http://archives.postgresql.org/pgsql-performance/2005-02/msg00030.php">http://archives.postgresql.org/pgsql-performance/2005-02/msg00030.php</ulink>をご覧下さい。
8 months ago
User avatar anonymous

Suggestion added

postgis_branch_32 / performance_tips — Japanese

The problem appears if you happen to have a table with rather large geometries, but not too many rows of them (like a table containing the boundaries of all European countries in high resolution). Then the table itself is small, but it uses lots of TOAST space. In our example case, the table itself had about 80 rows and used only 3 data pages, but the TOAST table used 8225 pages.
(高解像度で全てのヨーロッパの国の境界を含むテーブルのような)大きなジオメトリがあるうえ、行がそう多くないテーブルを持つようになると、この問題が出てきます。テーブル自体は小さいのですが、多くのTOASTスペースを使います。例として、テーブル自体は概ね80行で3データページしか使わなくてもTOASTテーブルで8225ページを使うとします。
8 months ago
User avatar anonymous

Suggestion added

postgis_branch_32 / performance_tips — Japanese

Performance Tips
性能向上に関する技法
8 months ago
User avatar None

New strings to translate

postgis_branch_32 / performance_tips — Japanese

8 new strings to translate appeared to the translation. a year ago
User avatar None

Resource update

postgis_branch_32 / performance_tips — Japanese

File doc/po/ja/performance_tips.xml.po was added. a year ago
Browse all translation changes