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

Re: Regarding Bitmap Scan

From: "soni de" <soni(dot)de(at)gmail(dot)com>
To: "Dawid Kuroczko" <qnex42(at)gmail(dot)com>, "A(dot) Kretschmer" <andreas(dot)kretschmer(at)schollglas(dot)com>
Cc: pgsql-performance(at)postgresql(dot)org
Subject: Re: Regarding Bitmap Scan
Date: 2006-10-27 13:12:35
Message-ID: 9f2e40a90610270612r75d9f52dh4aaf561995d42bd6@mail.gmail.com (view raw or flat)
Thread:
Lists: pgsql-performance
Thanks a lot for your help.

Thanks,
Soni


On 10/17/06, Dawid Kuroczko <qnex42(at)gmail(dot)com> wrote:
>
> On 10/17/06, soni de <soni(dot)de(at)gmail(dot)com> wrote:
> >
> >  I didn't understand the "Bitmap Scan" and the sentence "indexes will be
> > dynamically converted to bitmaps in memory". What does mean by "Bitmap Scan"
> > in database?
> >
> >
> >
> > Can anybody help us regarding above query?
> >
>
> Assume you have a table:
> CREATE TABLE foo (
>    some_key int,
>    some_time timestamp with time zone,
>    some_data text
> );
> And two indexes:
> CREATE INDEX foo_key ON foo (some_key);
> CREATE INDEX foo_time ON foo (some_time);
>
> Now, you make a query:
> SELECT * from foo WHERE some_key > 10 AND some_time >
> '2006-10-01'::timestamptz;
>
> ...originally planner would choose only one index to use -- and would use
> the
> one which it think its best.
>
> The 8.1 version does differently: It will scan foo_key index -- make a
> bitmap out of it,
> scan foo_time index -- make another bitmap out of it, binary AND these
> bitmaps,
> and will read the data from the table using such combined bitmap.  It
> could as well
> use "OR" if you used OR in your query.
>
> Hence -- it can be faster, especially for large tables and selective
> queries.
>
> Regards,
>    DAwid
>
>
>

In response to

pgsql-performance by date

Next:From: Merlin MoncureDate: 2006-10-27 13:49:34
Subject: Re: query produces 1 GB temp file
Previous:From: soni deDate: 2006-10-27 13:08:56
Subject: client crashes in PQfinish

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