Re: Big difference in time returned by EXPLAIN ANALYZE SELECT ... AND SELECT ...
От | Vitalii Tymchyshyn |
---|---|
Тема | Re: Big difference in time returned by EXPLAIN ANALYZE SELECT ... AND SELECT ... |
Дата | |
Msg-id | 4C4D547E.50905@gmail.com обсуждение исходный текст |
Ответ на | Re: Big difference in time returned by EXPLAIN ANALYZE SELECT ... AND SELECT ... (Craig Ringer <craig@postnewspapers.com.au>) |
Ответы |
Re: Big difference in time returned by EXPLAIN ANALYZE
SELECT ... AND SELECT ...
Re: Big difference in time returned by EXPLAIN ANALYZE SELECT ... AND SELECT ... |
Список | pgsql-performance |
26.07.10 12:15, Craig Ringer написав(ла): > On 26/07/10 16:35, Piotr Gasidło wrote: > >> Hello, >> >> I've found strange problem in my database (8.4.4, but also 9.0beta3, >> default postgresql.conf, shared_buffers raised to 256MB). >> >> EXPLAIN ANALYZE SELECT ... >> Total runtime: 4.782 ms >> Time: 25,970 ms >> >> SELECT ... >> ... >> (21 rows) >> >> Time: 23,042 ms >> >> Test done in psql connected by socket to server (same host, using >> \timing to get runtime). >> >> Does big difference in "Total runtime" and "Time" is normal? >> > Given that EXPLAIN ANALYZE doesn't transfer large rowsets to the client, > it can't really be time taken to transfer the data, which is the usual > difference between 'explain analyze' timings and psql client-side timings. > > Given that, I'm wondering if the difference in this case is planning > time. I can't really imagine the query planner taking 20 seconds (!!) to > run, though, no matter how horrifyingly complicated the query and table > structure were, unless there was something going wrong. > Actually it's 20ms, so I suspect your point about planning time is correct. Piotr: You can try preparing your statement and then analyzing execute time to check if this is planning time. Best regards, Vitalii Tymchyshyn
В списке pgsql-performance по дате отправления: