Re: Index Skip Scan

From: Jesper Pedersen <jesper(dot)pedersen(at)redhat(dot)com>
To: Dmitry Dolgov <9erthalion6(at)gmail(dot)com>
Cc: Alexander Korotkov <a(dot)korotkov(at)postgrespro(dot)ru>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Index Skip Scan
Date: 2018-06-19 17:06:08
Message-ID: 0b141c81-592b-cd43-fc6d-1b5ba0aaac57@redhat.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Hi Dmitry,

On 06/19/2018 06:01 AM, Dmitry Dolgov wrote:
>> On 18 June 2018 at 19:31, Alexander Korotkov <a(dot)korotkov(at)postgrespro(dot)ru> wrote:
>> Is skip scan only possible for index-only scan? I guess, that no. We
>> could also make plain index scan to behave like a skip scan. And it
>> should be useful for accelerating DISTINCT ON clause. Thus, we might
>> have 4 kinds of index scan: IndexScan, IndexOnlyScan, IndexSkipScan,
>> IndexOnlySkipScan. So, I don't think I like index scan nodes to
>> multiply this way, and it would be probably better to keep number
>> nodes smaller. But I don't insist on that, and I would like to hear
>> other opinions too.
>
> In one of patches I'm working on I had similar situation, when I wanted to
> split one node into two similar nodes (before I just extended it) and logically
> it made perfect sense. But it turned out to be quite useless and the advantage
> I've got wasn't worth it - and just to mention, those nodes had more differences
> than in this patch. So I agree that probably it would be better to keep using
> IndexOnlyScan.
>

I looked at this today, and creating a new node (T_IndexOnlySkipScan)
would make the patch more complex.

The question is if the patch should create such a node such that future
patches didn't have to deal with refactoring to a new node to cover
additional functionality.

Thanks for your feedback !

Best regards,
Jesper

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Tomas Vondra 2018-06-19 17:09:28 Re: WAL prefetch
Previous Message Robert Haas 2018-06-19 17:05:48 Re: Excessive CPU usage in StandbyReleaseLocks()