From: | Daniel Farina <daniel(at)heroku(dot)com> |
---|---|
To: | Yan Chunlu <springrider(at)gmail(dot)com> |
Cc: | pgsql-performance(at)postgresql(dot)org |
Subject: | Re: how could select id=xx so slow? |
Date: | 2012-07-06 09:46:18 |
Message-ID: | CAAZKuFZn3gXpr-b60+b_A6XqX8Do6P8hL770bcTg9BaLT0mBFw@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-performance |
On Thu, Jul 5, 2012 at 11:17 PM, Yan Chunlu <springrider(at)gmail(dot)com> wrote:
> I have grabbed one day slow query log and analyzed it by pgfouine, to my
> surprise, the slowest query is just a simple select statement:
>
> select diggcontent_data_message.thing_id, diggcontent_data_message.KEY,
> diggcontent_data_message.value, diggcontent_data_message.kind FROM
> diggcontent_data_message WHERE diggcontent_data_message.thing_id = 3570882;
>
>
> where thing_id is the primary key, guess how long it takes?
>
> 754.61 seconds!!
Is it possible that the size of the tuple is enormous? Because one
area where I've noticed EXPLAIN ANALYZE blows away normal performance
is when a lot of the work would be in reassembling, decompressing
(collectively: de-TOASTING) and sending the data.
Even then, that time seems excessive...but something to think about.
--
fdr
From | Date | Subject | |
---|---|---|---|
Next Message | Craig Ringer | 2012-07-06 11:16:27 | Re: how could select id=xx so slow? |
Previous Message | Craig Ringer | 2012-07-06 06:52:27 | Re: select operations that generate disk writes |