| From: | Korisk <Korisk(at)yandex(dot)ru> |
|---|---|
| To: | Ondrej Ivanič <ondrej(dot)ivanic(at)gmail(dot)com> |
| Cc: | Sergey Konoplev <gray(dot)ru(at)gmail(dot)com>, Craig Ringer <ringerc(at)ringerc(dot)id(dot)au>, "pgsql-performance(at)postgresql(dot)org" <pgsql-performance(at)postgresql(dot)org> |
| Subject: | Re: hash aggregation |
| Date: | 2012-10-12 14:37:48 |
| Message-ID: | 846851350052668@web19g.yandex.ru |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-performance |
> 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 btree (name)
after the table population.
Sizes:
hashes=# select pg_total_relation_size('hashcheck');
pg_total_relation_size
------------------------
2067701760
(1 row)
hashes=# select pg_total_relation_size('hashcheck_name_rev_idx');
pg_total_relation_size
------------------------
629170176
(1 row)
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Anibal David Acosta | 2012-10-12 20:05:52 | Do cast affects index usage? |
| Previous Message | Sergey Konoplev | 2012-10-12 07:10:06 | Re: hash aggregation |