| 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: | Whole Thread | Raw Message | 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 |