Thread: poor performance involving a small table

poor performance involving a small table

From

Colton A Smith

Date:

30 May 2005, 21:52:39

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!

Re: poor performance involving a small table

From

Bricklen Anderson

Date:

30 May 2005, 22:00:50

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.
_______________________________

Re: poor performance involving a small table

From

Christopher Kings-Lynne

Date:

31 May 2005, 01:51:14

>  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!

Does your table have millions of dead rows?  Do you vacuum once an hour?
  Run VACUUM FULL ANALYE sensor;

Chris

Re: poor performance involving a small table

From

andrew@pillette.com

Date:

31 May 2005, 02:31:17

This is a multi-part message in MIME format.

--bound1117506666
Content-Type: text/plain
Content-Transfer-Encoding: 7bit

Colton A Smith <smith@cs.utk.edu> wrote ..

------------------------------------------------------------------------------------------------
>   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)


Do you have some foreign keys pointing in the other direction? In other words, is there another table such that a
deleteon sensors causing a delete (or a check of some key) in another table? EXPLAIN doesn't show these. And that might
bea big table missing an index. 

--bound1117506666--