Re: [SQL] Indices are not used by the optimizer

From: Achilleus Mantzios <achill(at)matrix(dot)gatewaynet(dot)com>
To: Reiner Dassing <dassing(at)wettzell(dot)ifag(dot)de>
Cc: pgsql-sql(at)postgresql(dot)org, <pgsql-performance(at)postgresql(dot)org>
Subject: Re: [SQL] Indices are not used by the optimizer
Date: 2003-05-05 18:38:43
Message-ID: Pine.LNX.4.44.0305051624250.16184-100000@matrix.gatewaynet.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-performance pgsql-sql


Hi Reiner,

normally these kind of subjects must go
to pgsql-performance(at)postgresql(dot)org

What's important is in pg_class and pg_statistic tables.
Especially, you may check out histgraph bounds
in pg_stats for attribute epoche.

For a test, did you do a
# set enable_seqscan to OFF
??
On Mon, 5 May 2003, Reiner Dassing wrote:

> Hello all!
>
> On PostgreSQL V7.3.2 on TRU64 I have a table
> and applied indices for that table.
> But on a simple query the indices are not used by the optimizer.
> (An sequential scan is used which takes a lot of time)
> I have done
> VACUUM and VACUUM analyze
> but without any change to the optimizer.
>
> Can someone give me a hint what I should do to give the
> optimizer a start?
> --------------------------------------
>
> Well, let's start by the query
>
> wetter=# explain select * from wetter where epoche > '2001-01-01';
> QUERY PLAN
> -------------------------------------------------------------------------
> Seq Scan on wetter (cost=0.00..614795.55 rows=19054156 width=16)
> Filter: (epoche > '2001-01-01 00:00:00+00'::timestamp with time zone)
> (2 rows)
>
> wetter=#
>
>
> The table definition is as follows:
> \d wetter
> Table "public.wetter"
> Column | Type | Modifiers
> -----------+--------------------------+-----------
> sensor_id | integer | not null
> epoche | timestamp with time zone | not null
> wert | real | not null
> Indexes: wetter_pkey primary key btree (sensor_id, epoche),
> wetter_epoche_idx btree (epoche),
> wetter_sensor_id_idx btree (sensor_id)
> Triggers: RI_ConstraintTrigger_45702811,
> t_ins_wetter_wetterakt
>
> wetter=#
>
>
> The trigger information is as follows:
> select * from pg_trigger where tgname='RI_ConstraintTrigger_45702811';
> tgrelid | tgname | tgfoid | tgtype | tgenabled
> | tgisconstraint | tgconstrname | tgconstrrelid | tgdeferrable |
> tginitdeferred | tgnargs | tgattr |
> tgargs
> ----------+-------------------------------+--------+--------+-----------+----------------+--------------+---------------+--------------+----------------+---------+--------+---------------------------------------------------------------------------------------
> 43169106 | RI_ConstraintTrigger_45702811 | 1644 | 21 | t
> | t | <unnamed> | 43169098 | f | f
> | 6 | |
> <unnamed>\000wetter\000sensoren_an_orten\000UNSPECIFIED\000sensor_id\000sensor_id\000
> (1 row)
>
> wetter=#
>
>
> and t_ins_wetter_wetterakt
> is a PLPGSQL Funktion which copies some information into another table
> when an insert or update is done.
>
>
>

--
==================================================================
Achilleus Mantzios
S/W Engineer
IT dept
Dynacom Tankers Mngmt
Nikis 4, Glyfada
Athens 16610
Greece
tel: +30-210-8981112
fax: +30-210-8981877
email: achill(at)matrix(dot)gatewaynet(dot)com
mantzios(at)softlab(dot)ece(dot)ntua(dot)gr

In response to

Browse pgsql-performance by date

  From Date Subject
Next Message Josh Berkus 2003-05-05 19:19:58 Hypothetical suggestions for planner, indexing improvement
Previous Message Josh Berkus 2003-05-05 17:59:11 Re: Suggestions wanted for 7.2.4 query

Browse pgsql-sql by date

  From Date Subject
Next Message Alex Rice 2003-05-05 18:59:41 mnogosearch examples
Previous Message Michael A Nachbaur 2003-05-05 16:52:33 Replication for a large database