On 3/1/19 12:03 AM, Thomas Munro wrote: > On Fri, Mar 1, 2019 at 11:23 AM Jeff Janes <jeff.ja...@gmail.com> wrote: >> On Thu, Jan 31, 2019 at 1:32 AM Kyotaro HORIGUCHI >> <horiguchi.kyot...@lab.ntt.co.jp> wrote: >>> At Wed, 30 Jan 2019 18:19:05 +0100, Dmitry Dolgov <9erthali...@gmail.com> >>> wrote in >>> <CA+q6zcVP18wYiO=aa+fz3guncutf52q1sufb7ise37tjpsd...@mail.gmail.com> >>>> A bit of adjustment after nodes/relation -> nodes/pathnodes. >>> >>> I had a look on this. >>> >>> The name "index skip scan" is a different feature from the >>> feature with the name on other prodcuts, which means "index scan >>> with postfix key (of mainly of multi column key) that scans >>> ignoring the prefixing part" As Thomas suggested I'd suggest that >>> we call it "index hop scan". (I can accept Hopscotch, either:p) >> >> >> I think that what we have proposed here is just an incomplete implementation >> of what other products call a skip scan, not a fundamentally different >> thing. They don't ignore the prefix part, they use that part in a way to >> cancel itself out to give the same answer, but faster. I think they would >> also use this skip method to get distinct values if that is what is >> requested. But they would go beyond that to also use it to do something >> similar to the plan we get with this: > > Hi Jeff, > > "Hop scan" was just a stupid joke that occurred to me when I saw that > DB2 had gone for "jump scan". I think "skip scan" is a perfectly good > name and it's pretty widely used by now (for example, by our friends > over at SQLite to blow us away at these kinds of queries). >
+1 to "hop scan" regards -- Tomas Vondra http://www.2ndQuadrant.com PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
