Re: Wired behavor with LIMIT
От | Gregory Stark |
---|---|
Тема | Re: Wired behavor with LIMIT |
Дата | |
Msg-id | 877iqxko68.fsf@oxford.xeocode.com обсуждение исходный текст |
Ответ на | Re: Wired behavor with LIMIT (Thomas Munz <thomas@ecommerce.com>) |
Список | pgsql-general |
"Thomas Munz" <thomas@ecommerce.com> writes: > 100.000 entries less then the second one ) > is much slower then selecting all entries. This query was also 100 times > executed with allways the same result. > > explain ANALYZE select * from hd_conversation where action_int is null limit > 1552888;explain ANALYZE select * from hd_conversation where action_int is null; What are the results if you run the query without analyze. Use \timing to get the timing results, and use count(*) to avoid timing network speed: SELECT count(*) FROM (SELECT * FROM hd_conversation ... LIMIT 100000) I think your timing results are being dominated by the overhead it takes to actually measure the time spent in each node. With the limit node it has to call gettimeofday nearly twice as often. That works out to about 2.5us per gettimeofday which seems about right. -- Gregory Stark EnterpriseDB http://www.enterprisedb.com
В списке pgsql-general по дате отправления: