Re: Optimize single tuple fetch from nbtree index

Поиск
Список
Период
Сортировка
От Peter Geoghegan
Тема Re: Optimize single tuple fetch from nbtree index
Дата
Msg-id CAH2-Wznshq8VgJ6H3-qU=mGfvAPRaH9tnovC32G2MQcoVE9y8Q@mail.gmail.com
обсуждение исходный текст
Ответ на Re: Optimize single tuple fetch from nbtree index  (Peter Geoghegan <pg@bowt.ie>)
Ответы Re: Optimize single tuple fetch from nbtree index  (Michail Nikolaev <michail.nikolaev@gmail.com>)
Re: Optimize single tuple fetch from nbtree index  (Floris Van Nee <florisvannee@Optiver.com>)
Список pgsql-hackers
On Fri, Aug 2, 2019 at 5:34 PM Peter Geoghegan <pg@bowt.ie> wrote:
> I wonder if some variety of block nested loop join would be helpful
> here. I'm not aware of any specific design that would help with
> Floris' case, but the idea of reducing the number of scans required on
> the inner side by buffering outer side tuples (say based on the
> "k=:val" constant) seems like it might generalize well enough. I
> suggest Floris look into that possibility. This paper might be worth a
> read:
>
> https://dl.acm.org/citation.cfm?id=582278

Actually, having looked at the test case in more detail, that now
seems less likely. The test case seems designed to reward making it
cheaper to access one specific tuple among a fairly large group of
related tuples -- reducing the number of inner scans is not going to
be possible there.

If this really is totally representative of the case that Floris cares
about, I suppose that the approach taken more or less makes sense.
Unfortunately, it doesn't seem like an optimization that many other
users would find compelling, partly because it's only concerned with
fixed overheads, and partly because most queries don't actually look
like this.

-- 
Peter Geoghegan



В списке pgsql-hackers по дате отправления:

Предыдущее
От: Stephen Frost
Дата:
Сообщение: Re: [PATCH] Stop ALTER SYSTEM from making bad assumptions
Следующее
От: Andres Freund
Дата:
Сообщение: Re: [PATCH] Stop ALTER SYSTEM from making bad assumptions