Re: Index Skip Scan (new UniqueKeys)

From: Dmitry Dolgov <9erthalion6(at)gmail(dot)com>
To: Tomas Vondra <tomas(dot)vondra(at)enterprisedb(dot)com>
Cc: Heikki Linnakangas <hlinnaka(at)iki(dot)fi>, Peter Geoghegan <pg(at)bowt(dot)ie>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>, Jesper Pedersen <jesper(dot)pedersen(at)redhat(dot)com>, David Rowley <dgrowleyml(at)gmail(dot)com>, Floris Van Nee <florisvannee(at)optiver(dot)com>, Kyotaro Horiguchi <horikyota(dot)ntt(at)gmail(dot)com>, Thomas Munro <thomas(dot)munro(at)gmail(dot)com>, Tomas Vondra <tomas(dot)vondra(at)2ndquadrant(dot)com>, Andy Fan <zhihui(dot)fan1213(at)gmail(dot)com>, Dilip Kumar <dilipbalaut(at)gmail(dot)com>
Subject: Re: Index Skip Scan (new UniqueKeys)
Date: 2021-05-21 15:31:38
Message-ID: 20210521153138.kqvnnotxnn772b2a@localhost
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Hi,

Here is another take on the patch with a couple of changes:

* I've removed for now UniqueKeys parts. The interaction of skip scan &
unique keys patch was actually not that big, so the main difference is
that now the structure itself went away, a list of unique expressions
is used instead. All the suggestions about how this feature should
look like from the planning perspective are still there. On the one
hand it will allow to develop both patches independently and avoid
confusion for reviewers, on the other UniqueKeys could be easily
incorporated back when needed.

* Support for skipping in case of moving backward on demand (scroll
cursor) is moved into a separate patch. This is implemented via
returning false from IndexSupportsBackwardScan in case if it's a skip
scan node, which in turn adds Materialize node on top when needed. The
name SupportsBackwardScan was a bit confusing for me, but it seems
it's only being used with a cursorOptions check for CURSOR_OPT_SCROLL.
Eventually those cases when BackwardScanDirection is used are still
handled by amskip. This change didn't affect the test coverage, all
the test cases supported in previous patch versions are still there.

About Materialize node, I guess it could be less performant than a
"native" support, but it simplifies the implementation significantly
to the point that most parts, which were causing questions before, are
now located in the isolated patch. My idea here is to concentrate
efforts on the first three patches in this series, and consider the
rest of them as an experiment field.

* IndexScan support was also relocated into a separate patch, the first
three patches are now only about IndexOnlyScan.

* Last bits of reviews were incorporated and rebased.

Attachment Content-Type Size
v39-0001-Unique-expressions.patch text/x-diff 16.1 KB
v39-0002-Index-skip-scan.patch text/x-diff 40.7 KB
v39-0003-amskip-implementation-for-Btree.patch text/x-diff 33.3 KB
v39-0004-Extend-amskip-implementation-for-Btree.patch text/x-diff 20.6 KB
v39-0005-Index-skip-scan-for-IndexScan.patch text/x-diff 14.4 KB

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Robert Haas 2021-05-21 16:14:42 Re: Race condition in recovery?
Previous Message Dilip Kumar 2021-05-21 15:07:01 Re: Race condition in recovery?