Re: how could select id=xx so slow?
| От | Yan Chunlu |
|---|---|
| Тема | Re: how could select id=xx so slow? |
| Дата | |
| Msg-id | CAOA66tGPS0crmWXZ6tr6Y1-HvNOmuGV3Jfu8kg2U9yhdg2gPeQ@mail.gmail.com обсуждение исходный текст |
| Ответ на | Re: how could select id=xx so slow? (Craig Ringer <ringerc@ringerc.id.au>) |
| Ответы |
Re: how could select id=xx so slow?
Re: how could select id=xx so slow? |
| Список | pgsql-performance |
yes the system seems overloaded, I am dealing with a simple "INSERT" but not sure if it is normal that it took more time than the explain estimated:
explain analyze INSERT INTO vote_content ( thing1_id, thing2_id, name, date) VALUES (1,1, E'1', '2012-07-12T12:34:29.926863+00:00'::timestamptz)
QUERY PLAN
------------------------------------------------------------------------------------------
Insert (cost=0.00..0.01 rows=1 width=0) (actual time=79.610..79.610 rows=0 loops=1)
-> Result (cost=0.00..0.01 rows=1 width=0) (actual time=0.058..0.060 rows=1 loops=1)
Total runtime: 79.656 ms
it is a table with 50 million rows, so not sure if it is too large... I have attached the schema below:
Column | Type | Modifiers
-----------+--------------------------+------------------------------------------------------------------------------------
rel_id | bigint | not null default nextval('vote_content_rel_id_seq'::regclass)
thing1_id | bigint | not null
thing2_id | bigint | not null
name | character varying | not null
date | timestamp with time zone | not null
Indexes:
"vote_content_pkey" PRIMARY KEY, btree (rel_id)
"vote_content_thing1_id_key" UNIQUE, btree (thing1_id, thing2_id, name)
"idx_date_vote_content" btree (date)
"idx_name_vote_content" btree (name)
"idx_thing1_id_vote_content" btree (thing1_id)
"idx_thing1_name_date_vote_content" btree (thing1_id, name, date)
"idx_thing2_id_vote_content" btree (thing2_id)
"idx_thing2_name_date_vote_content" btree (thing2_id, name, date)
besides, it not the rush hour, so the disk IO is not the problem currently(I think):
Device: rrqm/s wrqm/s r/s w/s rkB/s wkB/s avgrq-sz avgqu-sz await r_await w_await svctm %util
sda 0.00 44.50 9.50 21.50 76.00 264.00 21.94 0.16 5.10 12.42 1.86 4.39 13.60
sdb 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00
On Thu, Jul 12, 2012 at 2:56 PM, Craig Ringer <ringerc@ringerc.id.au> wrote:
While true, you can often control this by making sure you don't completely overload your hardware, queuing queries instead of running them all at once.On 07/12/2012 01:10 PM, Yan Chunlu wrote:after check out the wiki page Maciek mentioned, turns out that heavy connection also burden the disk hardly.looks like I am in the vicious circle:1, slow query cause connection blocked so the client request more connection.2, more connection cause high disk io and make even the simplest query slow and block.
You may still discover that your hardware can't cope with the workload in that your queues may just keep on getting deeper or time out. In that case, you certainly need to optimise your queries, tune your database, and/or get bigger hardware.
--
Craig Ringer
В списке pgsql-performance по дате отправления: