| From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
|---|---|
| To: | Greg Stark <gsstark(at)mit(dot)edu> |
| Cc: | Robert Haas <robertmhaas(at)gmail(dot)com>, "Michael N(dot) Mikhulya" <m(dot)mikhulya(at)gmail(dot)com>, Matthew Wakeling <matthew(at)flymine(dot)org>, pgsql-performance(at)postgresql(dot)org |
| Subject: | Re: Idea how to get rid of Bitmap Heap Scan |
| Date: | 2009-12-20 16:26:38 |
| Message-ID: | 29932.1261326398@sss.pgh.pa.us |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-performance |
Greg Stark <gsstark(at)mit(dot)edu> writes:
> In the original poster's plan that isn't an issue. We could scan the
> index, perform the joins and restriction clauses, and only check the
> visibility on the resulting tuples which slip through them all. That
> would be possible even without crash-safe visibility bits.
Yeah, this was floated years ago as being a potentially interesting
approach when all the join-condition fields are indexed. You end up
never having to fetch rows that don't pass the join.
It certainly seems reasonably straightforward on the executor side.
As Greg said, the hard part is planning it sanely.
regards, tom lane
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Robert Haas | 2009-12-21 01:56:58 | Re: Idea how to get rid of Bitmap Heap Scan |
| Previous Message | Greg Stark | 2009-12-20 11:37:45 | Re: Idea how to get rid of Bitmap Heap Scan |