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
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() |