From: | Andres Freund <andres(at)anarazel(dot)de> |
---|---|
To: | Justin Pryzby <pryzby(at)telsasoft(dot)com> |
Cc: | Peter Geoghegan <pg(at)bowt(dot)ie>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org> |
Subject: | Re: kill_prior_tuple and index scan costing |
Date: | 2020-03-22 05:03:30 |
Message-ID: | 20200322050330.aleydhqs72oxge5u@alap3.anarazel.de |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Hi,
On 2020-03-21 23:53:05 -0500, Justin Pryzby wrote:
> On Sat, Mar 21, 2020 at 07:33:02PM -0700, Andres Freund wrote:
> > While your recent btree work ensures that we get the heap tids for an
> > equality lookup in heap order (right?),
>
> I think when I tested the TID tiebreaker patch, it didn't help for our case,
> which is for inequality: (timestamptz >= start AND timestamptz < end).
>
> That seems to explain why, although I don't understand why it wouldn't also
> apply to inequality comparison ?
Because tids are only ordered for a single lookup key. So if you scan
across multiple values you could have key:page visited in the order of
1:1 1:2 1:99 2:1 2:7 99:1 or such, i.e. the heap pages would not be
monotonically increasing. You can't however have 1:17 1:1, because for a
specific key value, the tid is used as an additional comparison value.
Greetings,
Andres Freund
From | Date | Subject | |
---|---|---|---|
Next Message | Pavel Stehule | 2020-03-22 06:48:14 | Re: BUG #16040: PL/PGSQL RETURN QUERY statement never uses a parallel plan |
Previous Message | Justin Pryzby | 2020-03-22 04:53:05 | Re: kill_prior_tuple and index scan costing |