| From: | Robert Haas <robertmhaas(at)gmail(dot)com> |
|---|---|
| To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
| Cc: | Leonardo F <m_lists(at)yahoo(dot)it>, pgsql-hackers(at)postgresql(dot)org |
| Subject: | Re: bitmap indexes - performance |
| Date: | 2010-07-01 15:40:22 |
| Message-ID: | AANLkTikbFpbFTySsUtzCDZOXfQaQJ05r9NuiNCHzWZ6C@mail.gmail.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On Thu, Jul 1, 2010 at 11:21 AM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> In particular, I recall some discussions about developing a "streaming
> API" whereby an index AM could return a bitmap page-by-page or so,
> rather than having to construct the whole thing in-memory before
> anything could happen. This would be a huge win for AND/OR cases,
> and even for a simple indexscan it would eliminate the existing startup
> cost penalty for a bitmap scan. Streaming like this would also
> eliminate the problem of having to lossify large bitmaps in order to
> not overrun memory.
Now that would be cool. The existing startup penalty for a bitmap
scan is the pits.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise Postgres Company
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Robert Haas | 2010-07-01 15:54:44 | Re: Cannot cancel the change of a tablespace |
| Previous Message | Tom Lane | 2010-07-01 15:21:26 | Re: bitmap indexes - performance |