Postgresのクエリが遅く、インデックス作成の可能性がありますか？

Question

かなり小さいデータベース（約300レコード）で8つのPostgresクエリを使用するWebアプリケーションを作成しています。繰り返しは不十分なクエリが1つしかありません。基本的にインデックス付きID番号で単一のレコードを検索し、さまざまなフィールドを収集した後、単一の結合を実行し、検索機能よりも遅く、300レコードすべてを処理する可能性があるまた、結合を実行します）。私はクエリを誤解しているのでしょうか、おそらく状況をスピードアップするインデックス作成の方法がありますか？ここで

SELECT id, title, datepub, description, comments,    
      price, publisher, placepub, numberofimages, name 
    FROM book 
    LEFT JOIN author 
     ON book.author = author.auth_id 
    WHERE id=11003 

はPosticoは、テーブルを作成する方法である：

 CREATE TABLE author (
     auth_id integer NOT NULL, 
     name character varying(250) 
    ); 

    CREATE SEQUENCE author_id_seq 
    START WITH 1 
    INCREMENT BY 1 
    NO MINVALUE 
    NO MAXVALUE 
    CACHE 1; 

    ALTER TABLE author_id_seq OWNER TO evanbates; 
    ALTER SEQUENCE author_id_seq OWNED BY author.auth_id; 

    ALTER TABLE ONLY author ALTER COLUMN auth_id SET DEFAULT 
    nextval('author_id_seq'::regclass); 

    ALTER TABLE ONLY author 
    ADD CONSTRAINT author_pkey PRIMARY KEY (auth_id); 

私は著者にインデックスを作成しました：

 CREATE TABLE book (
    id integer NOT NULL, 
    author integer, 
    title text, 
    subtitle text, 
    datepub text, 
    editiontext character varying(100), 
    description text, 
    comments text, 
    bindingtext character varying(50), 
    first boolean, 
    dj boolean, 
    signedtext boolean, 
    isbn character varying(25), 
    subject1 integer, 
    subject2 integer, 
    subject3 integer, 
    subject4 integer, 
    price numeric, 
    location character varying(50), 
    paid money, 
    keyword1 text, 
    bookcondition character varying(50), 
    featured boolean, 
    illustrator character varying(100), 
    quantity smallint, 
    dateadded date DEFAULT ('now'::text)::date, 
    publisher character varying(100), 
    placepub character varying(100), 
    numberofimages smallint, 
    imgurl text, 
    hook character varying(75), 
    display smallint DEFAULT '1'::smallint 
); 


    CREATE SEQUENCE book_id_seq 
    START WITH 1 
    INCREMENT BY 1 
    NO MINVALUE 
    NO MAXVALUE 
    CACHE 1; 


    ALTER TABLE book_id_seq OWNER TO evanbates; 
    ALTER SEQUENCE book_id_seq OWNED BY book.id; 

    ALTER TABLE ONLY book ALTER COLUMN id SET DEFAULT  
    nextval('book_id_seq'::regclass); 

    ALTER TABLE ONLY book 
    ADD CONSTRAINT book_pkey PRIMARY KEY (id); 

    ALTER TABLE ONLY book 
    ADD CONSTRAINT book_author_fkey FOREIGN KEY (author) REFERENCES  
    author(auth_id); 

    ALTER TABLE ONLY book 
    ADD CONSTRAINT book_subject1_fkey FOREIGN KEY (subject1) REFERENCES  
    subject(subj_id); 

    ALTER TABLE ONLY book 
    ADD CONSTRAINT book_subject2_fkey FOREIGN KEY (subject2) REFERENCES 
    subject(subj_id); 

    ALTER TABLE ONLY book 
    ADD CONSTRAINT book_subject3_fkey FOREIGN KEY (subject3) REFERENCES  
    subject(subj_id); 

    ALTER TABLE ONLY book 
    ADD CONSTRAINT book_subject4_fkey FOREIGN KEY (subject4) REFERENCES 
    subject(subj_id); 

：私は本のテーブルを作成し

 'CREATE UNIQUE INDEX author_pkey ON author USING btree (auth_id)' 

私は本の2つのインデックスを持っています：

CREATE UNIQUE INDEX book_pkey ON book USING btree (id) 

    and 

    CREATE INDEX first_idx ON book USING gin (title gin_trgm_ops) 

私はANALYZE EXPLAINです：

Hash Right Join (cost=8.18..15.35 rows=1 width=426) (actual time=0.089..0.093 rows=1 loops=1) 
     Hash Cond: (author.auth_id = book.author) 
     -> Seq Scan on author (cost=0.00..6.03 rows=303 width=33) (actual time=0.005..0.031 rows=304 loops=1) 
     -> Hash (cost=8.17..8.17 rows=1 width=401) (actual time=0.013..0.013 rows=1 
    loops=1) 
      Buckets: 1024 Batches: 1 Memory Usage: 9kB 
      -> Index Scan using book_pkey on book (cost=0.15..8.17 rows=1 width=401) (actual time=0.008..0.008 rows=1 loops=1) 
       Index Cond: (id = 11003) 

    Planning time: 0.213 ms 
    Execution time: 0.126 ms 
    (9 rows) 

CREATE INDEX book_author_idx ON book USING btree (author)を追加した後（下記参照）、私のANALYZE EXPLAINです：

Hash Right Join (cost=8.18..15.35 rows=1 width=426) (actual time=0.089..0.093 rows=1 loops=1) 
    Hash Cond: (author.auth_id = book.author) 
    -> Seq Scan on author (cost=0.00..6.03 rows=303 width=33) (actual time=0.005..0.035 rows=304 loops=1) 
    -> Hash (cost=8.17..8.17 rows=1 width=401) (actual time=0.012..0.012 rows=1 loops=1) 
      Buckets: 1024 Batches: 1 Memory Usage: 9kB 
      -> Index Scan using book_pkey on book (cost=0.15..8.17 rows=1 width=401) (actual time=0.008..0.009 rows=1 loops=1) 
       Index Cond: (id = 11003) 
    Planning time: 0.223 ms 
    Execution time: 0.127 ms 
    (9 rows) 

Answer 1

はpgAdminでを使用してPostgreSQLで直接クエリを実行してみます。また、含まれています

EXPLAIN ANALYZE 
    <YourQuery> 

私たちはオプティマイザによって作成された計画を見ることができます。 INDEX SEARCHの確認（良い）またはFULL SCAN（悪い）

私の推測では、あなたがIDのインデックスを持っていますが、auth_idのためにそうLEFT JOINが遅いではありません。 JOINフィールドにインデックスがあることを確認してください