From: | David Rowley <dgrowleyml(at)gmail(dot)com> |
---|---|
To: | Floris Van Nee <florisvannee(at)optiver(dot)com> |
Cc: | PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>, Andy Fan <zhihui(dot)fan1213(at)gmail(dot)com>, Jesper Pedersen <jesper(dot)pedersen(at)redhat(dot)com>, Kyotaro Horiguchi <horikyota(dot)ntt(at)gmail(dot)com>, Peter Geoghegan <pg(at)bowt(dot)ie>, Thomas Munro <thomas(dot)munro(at)gmail(dot)com>, Tomas Vondra <tomas(dot)vondra(at)2ndquadrant(dot)com>, Dilip Kumar <dilipbalaut(at)gmail(dot)com> |
Subject: | Re: Generic Index Skip Scan |
Date: | 2020-07-15 21:46:03 |
Message-ID: | CAApHDvqRk_qJ5GcYBuA2i6HYnib9aofh7ctUevq2PFvrW75cRA@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Thu, 16 Jul 2020 at 07:52, Floris Van Nee <florisvannee(at)optiver(dot)com> wrote:
>
> Besides the great efforts that Dmitry et al. are putting into the skip scan for DISTINCT queries [1], I’m also still keen on extending the use of it further. I’d like to address the limited cases in which skipping can occur here. A few months ago I shared an initial rough patch that provided a generic skip implementation, but lacked the proper planning work [2]. I’d like to share a second patch set that provides an implementation of the planner as well. Perhaps this can lead to some proper discussions how we’d like to shape this patch further.
>
> Please see [2] for an introduction and some rough performance comparisons. This patch improves upon those, because it implements proper cost estimation logic. It will now only choose the skip scan if it’s deemed to be cheaper than using a regular index scan. Other than that, all the features are still there. The skip scan can be used in many more types of queries than in the original DISTINCT patch as provided in [1], making it more performant and also more predictable for users.
>
> I’m keen on receiving feedback on this idea and on the patch.
I don't think anyone ever thought the feature would be limited to just
making DISTINCT go faster. There's certain to be more usages in the
future.
However, for me it would be premature to look at this now.
David
From | Date | Subject | |
---|---|---|---|
Next Message | Daniel Gustafsson | 2020-07-15 22:16:26 | Re: Support for NSS as a libpq TLS backend |
Previous Message | Tom Lane | 2020-07-15 21:45:35 | Re: gs_group_1 crashing on 13beta2/s390x |