Re: Optimize single tuple fetch from nbtree index - Mailing list pgsql-hackers

From Peter Geoghegan
Subject Re: Optimize single tuple fetch from nbtree index
Date
Msg-id CAH2-Wznshq8VgJ6H3-qU=mGfvAPRaH9tnovC32G2MQcoVE9y8Q@mail.gmail.com
Whole thread Raw
In response to Re: Optimize single tuple fetch from nbtree index  (Peter Geoghegan <pg@bowt.ie>)
Responses 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>)
List 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 by date:

Previous
From: Stephen Frost
Date:
Subject: Re: [PATCH] Stop ALTER SYSTEM from making bad assumptions
Next
From: Andres Freund
Date:
Subject: Re: [PATCH] Stop ALTER SYSTEM from making bad assumptions