Skip site navigation (1) Skip section navigation (2)

Re: [PERFORM] Slow query: bitmap scan troubles

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 (view raw or flat)
Thread:
Lists: pgsql-hackerspgsql-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.


In response to

pgsql-performance by date

Next:From: Merlin MoncureDate: 2013-01-07 19:22:13
Subject: Re: Two Necessary Kernel Tweaks for Linux Systems
Previous:From: ktm@rice.eduDate: 2013-01-07 18:28:11
Subject: Re: Sub optimal performance with default setting of Postgresql with FreeBSD 9.1 on ZFS

pgsql-hackers by date

Next:From: Alvaro HerreraDate: 2013-01-07 19:14:29
Subject: Re: recent ALTER whatever .. SET SCHEMA refactoring
Previous:From: Tom LaneDate: 2013-01-07 18:27:38
Subject: Re: [PERFORM] Slow query: bitmap scan troubles

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group