| From: | Jeff Davis <pgsql(at)j-davis(dot)com> |
|---|---|
| To: | Heikki Linnakangas <heikki(dot)linnakangas(at)enterprisedb(dot)com> |
| Cc: | Teodor Sigaev <teodor(at)sigaev(dot)ru>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org> |
| Subject: | Re: GIN, partial matches, lossy bitmaps |
| Date: | 2009-03-02 20:02:35 |
| Message-ID: | 1236024155.12092.14.camel@dell.linuxdev.us.dell.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On Mon, 2009-03-02 at 21:14 +0200, Heikki Linnakangas wrote:
> If I'm reading the code correctly, item pointers of all matching heap
> tuples are first collected into a TIDBitmap, and then amgetnext returns
> tuples from that one by one. If the bitmap becomes lossy, an error is
> thrown. gingetbitmap is a dummy implementation: it creates a new
> TIDBitmap and inserts all the tuples from the other TIDBitmap into it
> one by one, and then returns the new TIDBitmap.
Do you think that might be the cause of the extra startup overhead that
Robert Haas observed for bitmap scans?
> If we remove the support for regular, non-bitmap, index scans with GIN,
> that could be cleaned up as well. Even if we don't do that, gingetbitmap
> should not error when the bitmap becomes lossy, but just return the
> lossy bitmap.
That sounds reasonable to me.
Regards,
Jeff Davis
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Pavel Stehule | 2009-03-02 20:04:43 | Re: proposal: psql - breaking rows in white chars for wrapped format |
| Previous Message | Tom Lane | 2009-03-02 19:45:24 | Re: [BUGS] BUG #4680: Server crashed if using wrong (mismatch) conversion functions |