| From: | Jeff Janes <jeff(dot)janes(at)gmail(dot)com> |
|---|---|
| To: | Laurent Debacker <debackerl(at)gmail(dot)com> |
| Cc: | "pgsql-performance(at)postgresql(dot)org" <pgsql-performance(at)postgresql(dot)org> |
| Subject: | Re: bitmap heap scan recheck for gin/fts with no lossy blocks |
| Date: | 2015-07-24 22:27:28 |
| Message-ID: | CAMkU=1x01Oway2SY3b_UKmVPFmarwN6MnK0WhSuwuS08KMudHw@mail.gmail.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-performance |
On Fri, Jul 24, 2015 at 2:40 PM, Laurent Debacker <debackerl(at)gmail(dot)com>
wrote:
The Recheck Cond line is a plan-time piece of info, not a run-time piece.
> It only tells you what condition is going to be rechecked if a recheck is
> found to be necessary.
Thanks Jeff! That makes sense indeed.
>
> I'm a bit surprised a COUNT(1) would need a bitmap heap scan since we know
> the row count from the index, but okay.
>
Gin indexes do not (yet) implement index only scans. It has to visit the
block to check the visibility of the rows, as visibility data is not stored
in the index.
Cheers,
Jeff
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Mark Kirkwood | 2015-07-25 04:10:30 | Re: hyperthreadin low performance |
| Previous Message | Laurent Debacker | 2015-07-24 21:40:37 | Re: bitmap heap scan recheck for gin/fts with no lossy blocks |