From: | Dmitry Dolgov <9erthalion6(at)gmail(dot)com> |
---|---|
To: | David Rowley <dgrowleyml(at)gmail(dot)com> |
Cc: | Andy Fan <zhihui(dot)fan1213(at)gmail(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Ashutosh Bapat <ashutosh(dot)bapat(dot)oss(at)gmail(dot)com>, rushabh(dot)lathia(at)gmail(dot)com |
Subject: | Re: [PATCH] Keeps tracking the uniqueness with UniqueKey |
Date: | 2020-05-21 19:51:23 |
Message-ID: | 20200521195123.xv5as7lsdjl6ri2d@localhost |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
> On Tue, Apr 14, 2020 at 09:09:31PM +1200, David Rowley wrote:
>
> The infrastructure (knowing the unique properties of a RelOptInfo), as
> provided by the patch Andy has been working on, which is based on my
> rough prototype version, I believe should be used for the skip scans
> patch as well.
Hi,
Following our agreement about making skip scan patch to use UniqueKeys
implementation from this thread I've rebased index skip scan on first
two patches from v8 series [1] (if I understand correctly those two are
introducing the concept, and others are just using it). I would like to
clarify couple of things:
* It seems populate_baserel_uniquekeys, which actually sets uniquekeys,
is called after create_index_paths, where index skip scan already
needs to use them. Is it possible to call it earlier?
* Do I understand correctly, that a UniqueKey would be created in a
simplest case only when an index is unique? This makes it different
from what was implemented for index skip scan, since there UniqueKeys
also represents potential to use non-unique index to facilitate search
for unique values via skipping.
From | Date | Subject | |
---|---|---|---|
Next Message | David Rowley | 2020-05-21 20:40:17 | Re: [PATCH] Keeps tracking the uniqueness with UniqueKey |
Previous Message | Jeff Davis | 2020-05-21 19:40:23 | Re: Trouble with hashagg spill I/O pattern and costing |