| От | Stephan Szabo |
|---|---|
| Тема | Re: Slow SELECT with distinct, in a TIMESTAMP type column |
| Дата | |
| Msg-id | 20020624140056.B59376-100000@megazone23.bigpanda.com обсуждение исходный текст |
| Ответ на | Slow SELECT with distinct, in a TIMESTAMP type column (Marcos Garcia <marcos-p-garcia@ptinovacao.pt>) |
| Список | pgsql-sql |
On 24 Jun 2002, Marcos Garcia wrote: > > When i make the set enable_seqscan = off the result is: > > dbname=# set enable_seqscan = off; > SET VARIABLE > dbname=# explain analyze SELECT distinct(smsdate) FROM send_total; > > NOTICE: QUERY PLAN: > > Unique (cost=0.00..31084.39 rows=1232 width=8) (actual > time=108.60..195210.91 rows=6676 loops=1) > -> Index Scan using send_total_smsdate_idx on send_total > (cost=0.00..31053.60 rows=12315 width=8) (actual time=108.59..195145.43 > rows=12087 loops=1) > Total runtime: 195226.24 msec Well the plan choice makes sense (since it's about 3.5x faster as a sequence scan over the index scan). It looks like most of the time is taken up by the actual scan (is "select smsdate from send_total" pretty much as slow?).
В списке pgsql-sql по дате отправления:
Сайт использует файлы cookie для корректной работы и повышения удобства. Нажимая кнопку «Принять» или продолжая пользоваться сайтом, вы соглашаетесь на их использование в соответствии с Политикой в отношении обработки cookie ООО «ППГ», в том числе на передачу данных из файлов cookie сторонним статистическим и рекламным службам. Вы можете управлять настройками cookie через параметры вашего браузера