Re: Idea how to get rid of Bitmap Heap Scan - Mailing list pgsql-performance

From Greg Stark
Subject Re: Idea how to get rid of Bitmap Heap Scan
Date
Msg-id 407d949e0912180929j2718eff7x4db9dd45fdbfbe1e@mail.gmail.com
Whole thread Raw
In response to Re: Idea how to get rid of Bitmap Heap Scan  ("Michael N. Mikhulya" <m.mikhulya@gmail.com>)
Responses Re: Idea how to get rid of Bitmap Heap Scan
List pgsql-performance
On Fri, Dec 18, 2009 at 4:18 PM, Michael N. Mikhulya
<m.mikhulya@gmail.com> wrote:
> Thank you very much. I catch the point why it is done so.
>
> But I'm curious whether it is still possible to don't fetch data from
> files table just because inappropriate ids (e.g. removed ones) will
> not produce any wrong effect just because them indirectly "checked" on
> downloads table?
> Here I mean that if we get id (from index) for file which is actually
> removed, then we will not find anything in downloads table.
> Probably my knowledge about MVCC is too little to see whole picture,
> so if it is not hard to you please point the "failure" scenario (when
> we get wrong result) or locking issue, ...


Yup this ought to be possible and fruitful, I believe Heikki already
produced a partial patch to this end. If you're interested in working
on it you could skim back in the logs and start with that. I don't
recall any special keywords to search on but it might be in one of the
threads for the "visibility map" or it might be under "index-only
scans".

A word of warning, in my experience the hardest part for changes like
this isn't the executor changes (which in this case wouldn't be far
from easy) but the planner changes to detect when this new plan would
be better.

--
greg

pgsql-performance by date:

Previous
From: "Michael N. Mikhulya"
Date:
Subject: Re: Idea how to get rid of Bitmap Heap Scan
Next
From: Robert Haas
Date:
Subject: Re: Automatic optimization of IN clauses via INNER JOIN