| From: | Hannu Krosing <hannu(at)tm(dot)ee> |
|---|---|
| To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
| Cc: | Curt Sampson <cjs(at)cynic(dot)net>, mark Kirkwood <markir(at)slithery(dot)org>, Gavin Sherry <swm(at)linuxworld(dot)com(dot)au>, Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us>, pgsql-hackers(at)postgresql(dot)org |
| Subject: | Re: CLUSTER and indisclustered |
| Date: | 2002-08-07 04:46:29 |
| Message-ID: | 1028695589.2133.11.camel@rh72.home.ee |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On Wed, 2002-08-07 at 10:12, Tom Lane wrote:
> Curt Sampson <cjs(at)cynic(dot)net> writes:
> > On Wed, 7 Aug 2002, Tom Lane wrote:
> >> Also, the main downside of this approach is that the bitmap could
> >> get large --- but you could have some logic that causes you to fall
> >> back to plain sequential scan if you get too many index hits.
>
> > Well, what I was thinking of, should the list of TIDs to fetch get too
> > long, was just to break it down in to chunks.
>
> But then you lose the possibility of combining multiple indexes through
> bitmap AND/OR steps, which seems quite interesting to me. If you've
> visited only a part of each index then you can't apply that concept.
When the tuples are small relative to pagesize, you may get some
"compression" by saving just pages and not the actual tids in the the
bitmap.
-------------
Hannu
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Curt Sampson | 2002-08-07 04:48:51 | Re: Why is MySQL more chosen over PostgreSQL? |
| Previous Message | Tom Lane | 2002-08-07 04:43:19 | Re: Open 7.3 items |