web-dev-qa-db-ja.com

一時テーブルでのインデックスの使用

2つのかなり単純なクエリがあります。最初のクエリ

 UPDATE mp_physical SET periodic_number = '' WHERE periodic_number is NULL;

そしてそれは計画です

 duration: 0.125 ms  plan:
    Query Text: UPDATE mp_physical  SET periodic_number = '' WHERE periodic_number is NULL;
    Update on mp_physical  (cost=0.42..7.34 rows=1 width=801)
      ->  Index Scan using "_I_periodic_number" on mp_physical  (cost=0.42..7.34 rows=1 width=801)
            Index Cond: (periodic_number IS NULL)

そして2番目のもの：

 UPDATE observations_optical_temp SET designation = '' WHERE periodic_number is NULL;

そしてそれは計画です：

duration: 2817.375 ms  plan:
    Query Text: UPDATE observations_optical_temp SET periodic_number = '' WHERE periodic_number is NULL;
    Update on observations_optical_temp  (cost=103.55..9223.01 rows=5049 width=212)
      ->  Bitmap Heap Scan on observations_optical_temp  (cost=103.55..9223.01 rows=5049 width=212)
            Recheck Cond: (periodic_number IS NULL)
            ->  Bitmap Index Scan on "_I_per_num_temp"  (cost=0.00..102.29 rows=5049 width=0)
                  Index Cond: (periodic_number IS NULL)

2番目の計画は最初の計画と同じになると思います。しかし、そうではありません。どうして？ここにテーブルのダンプがあります。

CREATE TABLE public.mp_physical(
    id_mpp serial NOT NULL,
    id_comet_parts integer,
    "SPK_id" public.nonnegative_int,
    designation varchar(30),
    name varchar(100),
    prefix varchar,
    "is_NEO" bool,
    "H" double precision,
    "G" double precision,
    diameter public.nonnegative_double,
    extent varchar(30),
    extent_error public.nonnegative_double,
    geometric_albedo public.nonnegative_double,
    rot_per public.nonnegative_double,
    "GM" public.nonnegative_double,
    "BV" public.nonnegative_double,
    "UB" public.nonnegative_double,
    "spec_B" varchar(30),
    "spec_T" varchar(30),
    lca double precision,
    multiplicity public.nonnegative_int,
    polar_ang double precision,
    polar_slope_ang double precision,
    a double precision,
    b double precision,
    mass public.nonnegative_double,
    mp_type public.mp_type NOT NULL,
    periodic_number varchar(5),
    diameter_method_def varchar(200),
    discovery_info text,
    "H_sigma" public.nonnegative_double,
    "G_sigma" public.nonnegative_double,
    diameter_sigma public.nonnegative_double,
    geometric_albedo_sigma public.nonnegative_double,
    rot_per_sigma public.nonnegative_double,
    "GM_sigma" public.nonnegative_double,
    "BV_sigma" public.nonnegative_double,
    "UB_sigma" public.nonnegative_double,
    lca_sigma public.nonnegative_double,
    a_sigma public.nonnegative_double,
    b_sigma public.nonnegative_double,
    polar_ang_sigma public.nonnegative_double,
    mass_sigma public.nonnegative_double,
    CONSTRAINT "_C_id_ap" PRIMARY KEY (id_mpp)
);

CREATE INDEX "_I_name" ON  mp_physical  USING btree (name);
CREATE INDEX "_I_designation" ON mp_physical USING btree(mpp_designation);
CREATE INDEX "_I_periodic_number" ON mp_physical USING btree(periodic_number);
CREATE INDEX "_I_mp_type" ON mp_physical USING btree(mp_type);

そして

  CREATE TEMPORARY TABLE "observations_optical_temp"(note_1,date,"RA","Dec",magnitude,band,id_observatory,id_mpp,"Dec_degree",observatory_code,periodic_number,mpp_designation,mp_type)
AS SELECT note_1,date,"RA","Dec",magnitude,band,id_observatory,id_mpp,"Dec_degree",'1'::varchar(3),'1'::varchar(8),'1'::varchar(30),'A'::public.mp_type FROM observations_optical;

CREATE TABLE observations_optical(
    id_obs_o bigint
    note_1 varchar,
    date timestamp NOT NULL,
    "RA" time NOT NULL,
    "Dec_degree" integer NOT NULL,
    "Dec" time NOT NULL,
    magnitude double precision,
    band varchar,
    id_observatory integer,
    id_mpp integer,
    CONSTRAINT "_PK_id_obs_o" PRIMARY KEY (id_obs_o)
);
CREATE INDEX "_I_temp_1" ON observations_optical_temp USING btree(mpp_designation);
CREATE INDEX "_I_temp_2" ON observations_optical_temp USING btree(periodic_number);
CREATE INDEX "_I_temp_3" ON observations_optical_temp USING btree(mp_type);
postgresqlindexexecution-planperformancetemporary-tablespostgresql-performance
4
Artem Zefirov

インデックススキャンとビットマップインデックススキャンのどちらを選択するかは、基本的にPostgresが取得するデータページあたりの行数によって決まります。これは、テーブル内のデータ分布に関する統計とクエリ述語の選択性によって異なります。

Postgresが同じデータページで複数の行を見つけることを期待している場合は、ビットマップインデックススキャンに切り替わります。これは、この種の物理的なデータ分散により効率的です。 （とにかくほとんどのデータページが取得される場合、低順次スキャンの方が高速です。）したがって、2つのテーブルの列とインデックスがすべて同じに見えても、クエリのデータ分散と選択性によっては、これらの異なるクエリプランを取得できる場合があります。述語。

しかし、あなたのテーブルはそもそも非常に異なります。 mp_physicalの行ははるかに広いため、-同じデータにある行はほとんどありませんページ（デフォルトは8kb）のみです。これは、ビットマップインデックススキャンがすべての行のより高いパーセンテージを取得する場合でも（もしあれば）多くを購入しないため、インデックススキャンを非常に優先します。

また、一時テーブルはautovacuumの対象ではないため、自動的に分析されないことに注意してください。クエリプランナーが使用するための正確なテーブル統計を取得するには、これを手動で行う必要がある場合があります。

ANALYZE observations_optical_temp;
4
Erwin Brandstetter