Re: Idea how to get rid of Bitmap Heap Scan

Поиск
Список
Период
Сортировка
От Greg Stark
Тема Re: Idea how to get rid of Bitmap Heap Scan
Дата
Msg-id 407d949e0912180929j2718eff7x4db9dd45fdbfbe1e@mail.gmail.com
обсуждение исходный текст
Ответ на Re: Idea how to get rid of Bitmap Heap Scan  ("Michael N. Mikhulya" <m.mikhulya@gmail.com>)
Ответы Re: Idea how to get rid of Bitmap Heap Scan
Список 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 по дате отправления:

Предыдущее
От: "Michael N. Mikhulya"
Дата:
Сообщение: Re: Idea how to get rid of Bitmap Heap Scan
Следующее
От: Robert Haas
Дата:
Сообщение: Re: Automatic optimization of IN clauses via INNER JOIN