Re: Index Skip Scan

From: Kyotaro HORIGUCHI <horiguchi(dot)kyotaro(at)lab(dot)ntt(dot)co(dot)jp>
To: 9erthalion6(at)gmail(dot)com
Cc: jeff(dot)janes(at)gmail(dot)com, thomas(dot)munro(at)gmail(dot)com, jesper(dot)pedersen(at)redhat(dot)com, a(dot)kuzmenkov(at)postgrespro(dot)ru, pg(at)bowt(dot)ie, tomas(dot)vondra(at)2ndquadrant(dot)com, thomas(dot)munro(at)enterprisedb(dot)com, bhushan(dot)uparkar(at)gmail(dot)com, pgsql-hackers(at)postgresql(dot)org, a(dot)korotkov(at)postgrespro(dot)ru, jtc331(at)gmail(dot)com
Subject: Re: Index Skip Scan
Date: 2019-03-15 00:51:57
Message-ID: 20190315.095157.248738584.horiguchi.kyotaro@lab.ntt.co.jp
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

At Thu, 14 Mar 2019 14:32:49 +0100, Dmitry Dolgov <9erthalion6(at)gmail(dot)com> wrote in <CA+q6zcUSuFBhGVFZN_AVSxRbt5wr_4_YEYwv8PcQB=m6J6Zpvg(at)mail(dot)gmail(dot)com>
> > On Tue, Mar 5, 2019 at 4:05 PM Dmitry Dolgov <9erthalion6(at)gmail(dot)com> wrote:
> >
> > Although there are still some rough edges, e.g. going forth, back and forth
> > again leads to a sutiation, when `_bt_first` is not applied anymore and the
> > first element is wrongly skipped. I'll try to fix it with the next version of
> > patch.
>
> It turns out that `_bt_skip` was unnecessary applied every time when scan was
> restarted from the beginning. Here is the fixed version of patch.

> nbtsearch.c: In function ‘_bt_skip’:
> nbtsearch.c:1292:11: error: ‘struct IndexScanDescData’ has no member named ‘xs_ctup’; did you mean ‘xs_itup’?
> scan->xs_ctup.t_self = currItem->heapTid;

Unfortunately a recent commit c2fe139c20 hit this.

Date: Mon Mar 11 12:46:41 2019 -0700
> Index scans now store the result of a search in
> IndexScanDesc->xs_heaptid, rather than xs_ctup->t_self. As the
> target is not generally a HeapTuple anymore that seems cleaner.

regards.

--
Kyotaro Horiguchi
NTT Open Source Software Center

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Imai, Yoshikazu 2019-03-15 01:38:22 RE: speeding up planning with partitions
Previous Message Michael Paquier 2019-03-15 00:49:42 Re: Offline enabling/disabling of data checksums