Re: poor performance involving a small table

From: Bricklen Anderson <BAnderson(at)PresiNET(dot)com>
To: Colton A Smith <smith(at)cs(dot)utk(dot)edu>
Cc: pgsql-performance(at)postgresql(dot)org
Subject: Re: poor performance involving a small table
Date: 2005-05-30 22:00:37
Message-ID: 429B8D05.5040705@PresiNET.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-performance

Colton A Smith wrote:
>
> Hi:
>
> I have a table called sensors:
>
> Table "public.sensor"
> Column | Type | Modifiers
> -----------------+--------------------------+-------------------------------------------------
>
> sensor_id | integer | not null default
> nextval('sensor_id_seq'::text)
> sensor_model_id | integer | not null
> serial_number | character varying(50) | not null
> purchase_date | timestamp with time zone | not null
> variable_id | integer | not null
> datalink_id | integer | not null
> commentary | text |
> Indexes:
> "sensor_pkey" PRIMARY KEY, btree (sensor_id)
> Foreign-key constraints:
> "datalink_id_exists" FOREIGN KEY (datalink_id) REFERENCES
> datalink(datalink_id) ON DELETE RESTRICT
> "sensor_model_id_exists" FOREIGN KEY (sensor_model_id) REFERENCES
> sensor_model(sensor_model_id) ON DELETE RESTRICT
> "variable_id_exists" FOREIGN KEY (variable_id) REFERENCES
> variable(variable_id) ON DELETE RESTRICT
>
>
> Currently, it has only 19 rows. But when I try to delete a row, it takes
> forever. I tried restarting the server. I tried a full vacuum to no
> avail. I tried the following:
>
> explain analyze delete from sensor where sensor_id = 12;
> QUERY PLAN
> ------------------------------------------------------------------------------------------------
>
> Seq Scan on sensor (cost=0.00..1.25 rows=1 width=6) (actual
> time=0.055..0.068 rows=1 loops=1)
> Filter: (sensor_id = 12)
> Total runtime: 801641.333 ms
> (3 rows)
>
> Can anybody help me out? Thanks so much!
>

I'd say the obvious issue would be your foreign keys slowing things down. Have
you analyzed the referenced tables, and indexed the columns on the referenced
tables?

--
_______________________________

This e-mail may be privileged and/or confidential, and the sender does
not waive any related rights and obligations. Any distribution, use or
copying of this e-mail or the information it contains by other than an
intended recipient is unauthorized. If you received this e-mail in
error, please advise me (by return e-mail or otherwise) immediately.
_______________________________

In response to

Browse pgsql-performance by date

  From Date Subject
Next Message Yves Vindevogel 2005-05-30 22:06:49 Drop / create indexes and vacuumdb
Previous Message Tom Lane 2005-05-30 17:57:54 Re: timestamp indexing