| From: | Claudio Freire <klaussfreire(at)gmail(dot)com> |
|---|---|
| To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
| Cc: | Simon Riggs <simon(at)2ndquadrant(dot)com>, Jeff Janes <jeff(dot)janes(at)gmail(dot)com>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org> |
| Subject: | Re: [PERFORM] Slow query: bitmap scan troubles |
| Date: | 2013-01-07 18:48:12 |
| Message-ID: | CAGTBQpbNJLx+QjksoA4wmChBDkzkBgfxXLDkgaKKrku+JfvqXg@mail.gmail.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers pgsql-performance |
On Mon, Jan 7, 2013 at 3:27 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>
> One issue that needs some thought is that the argument for this formula
> is based entirely on thinking about b-trees. I think it's probably
> reasonable to apply it to gist, gin, and sp-gist as well, assuming we
> can get some estimate of tree height for those, but it's obviously
> hogwash for hash indexes. We could possibly just take H=0 for hash,
> and still apply the log2(N) part ... not so much because that is right
> as because it's likely too small to matter.
Height would be more precisely "lookup cost" (in comparisons). Most
indexing structures have a well-studied lookup cost. For b-trees, it's
log_b(size), for hash it's 1 + size/buckets.
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Alvaro Herrera | 2013-01-07 19:14:29 | Re: recent ALTER whatever .. SET SCHEMA refactoring |
| Previous Message | Tom Lane | 2013-01-07 18:27:38 | Re: [PERFORM] Slow query: bitmap scan troubles |
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Merlin Moncure | 2013-01-07 19:22:13 | Re: Two Necessary Kernel Tweaks for Linux Systems |
| Previous Message | ktm@rice.edu | 2013-01-07 18:28:11 | Re: Sub optimal performance with default setting of Postgresql with FreeBSD 9.1 on ZFS |