pg.ddx.io pgsql-performance@postgresql.org mailing list archive
help / color / mirror / Atom feedpoor performance involving a small table
4+ messages / 4 participants
[nested] [flat]
* poor performance involving a small table
@ 2005-05-26 14:57 Colton A Smith <smith@cs.utk.edu>
2005-05-30 22:00 ` Re: poor performance involving a small table Bricklen Anderson <BAnderson@PresiNET.com>
2005-05-31 01:52 ` Re: poor performance involving a small table Christopher Kings-Lynne <chriskl@familyhealth.com.au>
0 siblings, 2 replies; 4+ messages in thread
From: Colton A Smith @ 2005-05-26 14:57 UTC (permalink / raw)
To: pgsql-performance
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!
^ permalink raw reply [nested|flat] 4+ messages in thread
* Re: poor performance involving a small table
2005-05-26 14:57 poor performance involving a small table Colton A Smith <smith@cs.utk.edu>
@ 2005-05-30 22:00 ` Bricklen Anderson <BAnderson@PresiNET.com>
1 sibling, 0 replies; 4+ messages in thread
From: Bricklen Anderson @ 2005-05-30 22:00 UTC (permalink / raw)
To: Colton A Smith <smith@cs.utk.edu>; +Cc: 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.
_______________________________
^ permalink raw reply [nested|flat] 4+ messages in thread
* Re: poor performance involving a small table
2005-05-26 14:57 poor performance involving a small table Colton A Smith <smith@cs.utk.edu>
@ 2005-05-31 01:52 ` Christopher Kings-Lynne <chriskl@familyhealth.com.au>
1 sibling, 0 replies; 4+ messages in thread
From: Christopher Kings-Lynne @ 2005-05-31 01:52 UTC (permalink / raw)
To: Colton A Smith <smith@cs.utk.edu>; +Cc: pgsql-performance
> 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
^ permalink raw reply [nested|flat] 4+ messages in thread
* Re: poor performance involving a small table
@ 2005-05-31 02:31 andrew@pillette.com
0 siblings, 0 replies; 4+ messages in thread
From: andrew@pillette.com @ 2005-05-31 02:31 UTC (permalink / raw)
To: Colton A Smith <smith@cs.utk.edu>; +Cc: pgsql-performance
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 delete on sensors causing a delete (or a check of some key) in another table? EXPLAIN doesn't show these. And that might be a big table missing an index.
--bound1117506666--
^ permalink raw reply [nested|flat] 4+ messages in thread
end of thread, other threads:[~2005-05-31 02:31 UTC | newest]
Thread overview: 4+ messages (download: mbox mbox.gz follow: Atom feed)
-- links below jump to the message on this page --
2005-05-26 14:57 poor performance involving a small table Colton A Smith <smith@cs.utk.edu>
2005-05-30 22:00 ` Bricklen Anderson <BAnderson@PresiNET.com>
2005-05-31 01:52 ` Christopher Kings-Lynne <chriskl@familyhealth.com.au>
2005-05-31 02:31 Re: poor performance involving a small table andrew@pillette.com
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox