> What I can not understand is why the seq scan's estimated cost is
> better the index scan's one. It depends on the number of pages in
> index/relation. May be the index is heavily bloated?
Mm i don't know how to see bloating level. But the index was created by
create index on hashcheck using btr
Strange situation.
After indexscan enabling the cost is seriously decreased.
hashes=# set enable_bitmapscan=on;
SET
hashes=# explain analyse verbose select name, count(name) as cnt from
hashcheck group by name order by name desc;
0
Total runtime: 7272.735 ms
(6 rows)
11.10.2012, 21:55, "Sergey Konoplev" :
> On Thu, Oct 11, 2012 at 8:15 AM, Korisk wrote:
>
>> What's your seq_page_cost and random_page_cost?
>> hashes=# SELECT name, setting, reset_val FROM pg_settings WHERE se
"IOS scan" ?
Index Only Scan
What's your seq_page_cost and random_page_cost?
hashes=# SELECT name, setting, reset_val FROM pg_settings WHERE setting <>
reset_val;
name |setting | reset_val
-++---
archive_command
e=0.104..3785.767 rows=25990002 loops=1)
Output: name
Heap Fetches: 0
Total runtime: 7452.509 ms
(6 rows)
Благодаря шаманствам на:
http://www.sql.ru/forum/actualthread.aspx?tid=974484
11.10.2012, 01:30, "Sergey Konoplev" :
> On Wed, Oct 10, 2012 at 9:09 AM, Korisk
Hello! Is it possible to speed up the plan?
hashes=# \d hashcheck
Table "public.hashcheck"
Column | Type| Modifiers
+---+
id
I have table:
create table hashcheck(id serial, name varchar, value varchar);
and query:
hashaggr=# explain analyse verbose select name, count(name) as cnt from
hashcheck group by name order by name desc;
QUERY PLAN
