Re: WIP: Covering + unique indexes.

I'm wondering what's the genesis of this coninclude column actually. As far as I can tell, the only reason this column is there, is to be able to print the INCLUDE clause in a UNIQUE/PK constraint in ruleutils ... but surely the same list can be obtained from the pg_index.indkey instead? --

Re: WIP: Covering + unique indexes.

Thank you, pushed Peter Geoghegan wrote: On Wed, Apr 18, 2018 at 10:47 PM, Teodor Sigaev wrote: Thank you, pushed. Thanks. I saw another preexisting issue, this time one that has been around since 2007. Commit bc292937 forgot to remove a comment above _bt_insertonpg()

Re: WIP: Covering + unique indexes.

On Wed, Apr 18, 2018 at 10:47 PM, Teodor Sigaev wrote: > Thank you, pushed. Thanks. I saw another preexisting issue, this time one that has been around since 2007. Commit bc292937 forgot to remove a comment above _bt_insertonpg() (the 'afteritem' stuff ended up being moved to

Re: WIP: Covering + unique indexes.

Thank you, pushed. Actually, I see one tiny issue with extra '*' characters here: +* The number of attributes won't be explicitly represented if the +* negative infinity tuple was generated during a page split that +* occurred with a version of Postgres

Re: WIP: Covering + unique indexes.

On Wed, Apr 18, 2018 at 1:45 PM, Peter Geoghegan wrote: > I suggest committing this patch as-is. Actually, I see one tiny issue with extra '*' characters here: > +* The number of attributes won't be explicitly represented if the > +* negative infinity tuple

Re: WIP: Covering + unique indexes.

On Wed, Apr 18, 2018 at 1:32 PM, Teodor Sigaev wrote: >> I don't understand. We do check the number of attributes on rightmost >> pages, but we do so separately, in the main loop. For every item that >> isn't the high key. > > Comment added, pls, verify. And refactored

Re: WIP: Covering + unique indexes.

I don't understand. We do check the number of attributes on rightmost pages, but we do so separately, in the main loop. For every item that isn't the high key. Comment added, pls, verify. And refactored _bt_check_natts(), I hope, now it's a bit more readable. 4) BTreeTupSetNAtts - seems, it's

Re: WIP: Covering + unique indexes.

(() On Wed, Apr 18, 2018 at 10:10 AM, Teodor Sigaev wrote: > I mostly agree with your patch, nice work, but I have some notices for your > patch: Thanks. > 1) > bt_target_page_check(): > if (!P_RIGHTMOST(topaque) && > !_bt_check_natts(state->rel, state->target,

Re: WIP: Covering + unique indexes.

I mostly agree with your patch, nice work, but I have some notices for your patch: 1) bt_target_page_check(): if (!P_RIGHTMOST(topaque) && !_bt_check_natts(state->rel, state->target, P_HIKEY)) Seems not very obvious: it looks like we don't need to check nattrs on rightmost page.

Re: WIP: Covering + unique indexes.

On Tue, Apr 17, 2018 at 3:12 AM, Alexander Korotkov wrote: > Hmm, what do you think about making BTreeTupGetNAtts() take tupledesc > argument, not relation> It anyway doesn't need number of key attributes, > only total number of attributes. Then _bt_isequal() would be

Re: WIP: Covering + unique indexes.

On Mon, Apr 16, 2018 at 1:05 AM, Peter Geoghegan wrote: > Attached patch makes the changes that I talked about, and a few > others. The commit message has full details. The general direction of > the patch is that it documents our assumptions, and verifies them in > more cases.

Re: WIP: Covering + unique indexes.

On Thu, Apr 12, 2018 at 9:21 AM, Teodor Sigaev wrote: > Agree, I prefer to add more Assert, even. may be, more than actually needed. > Assert-documented code :) Absolutely. The danger with a feature like this is that we'll miss one place. I suppose that you could say that I am

Re: WIP: Covering + unique indexes.

Hi! > 12 апр. 2018 г., в 21:21, Teodor Sigaev написал(а): I was adapting tests for GiST covering index and found out that REINDEX test is somewhat not a REINDEX test... I propose following micropatch. Best regards, Andrey Borodin. fix-reindex-test.diff Description: Binary

Re: WIP: Covering + unique indexes.

Peter Geoghegan wrote: On Tue, Apr 10, 2018 at 5:45 PM, Peter Geoghegan wrote: I did find another problem, though. Looks like the idea to explicitly represent the number of attributes directly has paid off already: pg@~[3711]=# create table covering_bug (f1 int, f2 int, f3

Re: WIP: Covering + unique indexes.

On Tue, Apr 10, 2018 at 5:45 PM, Peter Geoghegan wrote: > I did find another problem, though. Looks like the idea to explicitly > represent the number of attributes directly has paid off already: > > pg@~[3711]=# create table covering_bug (f1 int, f2 int, f3 text); > create unique

Re: WIP: Covering + unique indexes.

_bt_mark_page_halfdead() looked like it had a problem, but it now looks like I was wrong. I also verified every other BTreeInnerTupleGetDownLink() caller. It now looks like everything is good here. Right - it tries to find right page by conlsulting in parent page, by taking of next key. --

Re: WIP: Covering + unique indexes.

On Tue, Apr 10, 2018 at 1:37 PM, Peter Geoghegan wrote: > _bt_mark_page_halfdead() looked like it had a problem, but it now > looks like I was wrong. I did find another problem, though. Looks like the idea to explicitly represent the number of attributes directly has paid off

Re: WIP: Covering + unique indexes.

On Tue, Apr 10, 2018 at 9:03 AM, Teodor Sigaev wrote: >> * Not sure that all calls to BTreeInnerTupleGetDownLink() are limited >> to inner tuples, which might be worth doing something about (perhaps >> just renaming the macro). > > What is suspicious place for you opinion?

Re: WIP: Covering + unique indexes.

* There is no pfree() within _bt_buildadd() for truncated tuples, even though that's a context where it's clearly not okay. Agree * It might be a good idea to also pfree() the truncated tuple for most other _bt_buildadd() callers. Even though it's arguably okay in other cases, it seems worth

Re: WIP: Covering + unique indexes.

On Sun, Apr 8, 2018 at 11:19 PM, Teodor Sigaev wrote: > Thank you, pushed. I noticed a few more issues following another pass-through of the patch: * There is no pfree() within _bt_buildadd() for truncated tuples, even though that's a context where it's clearly not okay. * It

Re: WIP: Covering + unique indexes.

<noriyoshi.shin...@hpe.com> *Cc:* PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>; Teodor Sigaev <teo...@sigaev.ru>; Peter Geoghegan <p...@bowt.ie>; Jeff Janes <jeff.ja...@gmail.com>; Anastasia Lubennikova <a.lubennik...@postgrespro.ru> *Subject:* Re:

RE: WIP: Covering + unique indexes.

l-hackers@lists.postgresql.org>; Teodor Sigaev <teo...@sigaev.ru>; Peter Geoghegan <p...@bowt.ie>; Jeff Janes <jeff.ja...@gmail.com>; Anastasia Lubennikova <a.lubennik...@postgrespro.ru> Subject: Re: WIP: Covering + unique indexes. Hi! On Mon, Apr 9, 2018 at 5:07 PM,

Re: WIP: Covering + unique indexes.

Hi! On Mon, Apr 9, 2018 at 5:07 PM, Shinoda, Noriyoshi < noriyoshi.shin...@hpe.com> wrote: > I tested this feature and found a document shortage in the columns added > to the pg_constraint catalog. > The attached patch will add the description of the 'conincluding' column > to the manual of the

RE: WIP: Covering + unique indexes.

Hackers <pgsql-hackers@lists.postgresql.org> Subject: Re: WIP: Covering + unique indexes. Thank you, pushed. Peter Geoghegan wrote: > On Sun, Apr 8, 2018 at 11:18 AM, Teodor Sigaev <teo...@sigaev.ru> wrote: >> Thank you, fixed > > I suggest that we remove some unneeded amcheck tests,

Re: WIP: Covering + unique indexes.

Thank you, pushed. Peter Geoghegan wrote: On Sun, Apr 8, 2018 at 11:18 AM, Teodor Sigaev wrote: Thank you, fixed I suggest that we remove some unneeded amcheck tests, as in the attached patch. They don't seem to add anything. -- Teodor Sigaev

Re: WIP: Covering + unique indexes.

On Sun, Apr 8, 2018 at 11:18 AM, Teodor Sigaev wrote: > Thank you, fixed I suggest that we remove some unneeded amcheck tests, as in the attached patch. They don't seem to add anything. -- Peter Geoghegan From 0dbbee5bfff8816cddf86961bf4959192f62f1ff Mon Sep 17 00:00:00 2001

Re: WIP: Covering + unique indexes.

Thanks to everyone, pushed. Indeed thanks, this will be a nice feature. It is giving me a compiler warning on non-cassert builds using gcc (Ubuntu 5.4.0-6ubuntu1~16.04.9) 5.4.0 20160609: indextuple.c: In function 'index_truncate_tuple': indextuple.c:462:6: warning: unused variable

Re: WIP: Covering + unique indexes.

Thank you, fixed Jeff Janes wrote: On Sat, Apr 7, 2018 at 4:02 PM, Teodor Sigaev > wrote: Thanks to everyone, pushed. Indeed thanks, this will be a nice feature. It is giving me a compiler warning on non-cassert builds using gcc (Ubuntu

Re: WIP: Covering + unique indexes.

On Sat, Apr 7, 2018 at 4:02 PM, Teodor Sigaev wrote: > Thanks to everyone, pushed. > > Indeed thanks, this will be a nice feature. It is giving me a compiler warning on non-cassert builds using gcc (Ubuntu 5.4.0-6ubuntu1~16.04.9) 5.4.0 20160609: indextuple.c: In function

Re: WIP: Covering + unique indexes.

> "Teodor" == Teodor Sigaev writes: >> Support for testing amcaninclude via >> pg_indexam_has_property(oid,'can_include') seems to be missing? >> >> Also the return values of pg_index_column_has_property for included >> columns seem a bit dubious... should probably be

Re: WIP: Covering + unique indexes.

Support for testing amcaninclude via pg_indexam_has_property(oid,'can_include') seems to be missing? Also the return values of pg_index_column_has_property for included columns seem a bit dubious... should probably be returning NULL for most properties except 'returnable'. Damn, you right, it's

Re: WIP: Covering + unique indexes.

On Sat, Apr 7, 2018 at 1:52 PM, Andrew Gierth wrote: > Support for testing amcaninclude via > pg_indexam_has_property(oid,'can_include') seems to be missing? > > Also the return values of pg_index_column_has_property for included > columns seem a bit dubious... should

Re: WIP: Covering + unique indexes.

> "Teodor" == Teodor Sigaev writes: >> I'll keep an eye on the buildfarm, since it's late in Russia. Teodor> Thank you very much! Now 23:10 MSK and I'll be able to follow Teodor> during approximately hour. Support for testing amcaninclude via

Re: WIP: Covering + unique indexes.

Thank you, I looked to buildfarm and completely forget about commitfest site Andres Freund wrote: On 2018-04-07 23:02:08 +0300, Teodor Sigaev wrote: Thanks to everyone, pushed. Marked CF entry as committed. Greetings, Andres Freund -- Teodor Sigaev E-mail:

Re: WIP: Covering + unique indexes.

On 2018-04-07 23:02:08 +0300, Teodor Sigaev wrote: > Thanks to everyone, pushed. Marked CF entry as committed. Greetings, Andres Freund

Re: WIP: Covering + unique indexes.

I'll keep an eye on the buildfarm, since it's late in Russia. Thank you very much! Now 23:10 MSK and I'll be able to follow during approximately hour. -- Teodor Sigaev E-mail: teo...@sigaev.ru WWW: http://www.sigaev.ru/

Re: WIP: Covering + unique indexes.

On Sat, Apr 7, 2018 at 1:02 PM, Teodor Sigaev wrote: > Thanks to everyone, pushed. I'll keep an eye on the buildfarm, since it's late in Russia. -- Peter Geoghegan

Sv: Re: WIP: Covering + unique indexes.

På lørdag 07. april 2018 kl. 22:02:08, skrev Teodor Sigaev >: Thanks to everyone, pushed.   Rock!   -- Andreas Joseph Krogh  

Re: WIP: Covering + unique indexes.

Thanks to everyone, pushed. Peter Geoghegan wrote: On Sat, Apr 7, 2018 at 5:48 AM, Teodor Sigaev wrote: On close look, bts_btentry.ip_posid is not used anymore, I change bts_btentry type to BlockNumber. As result, BTEntrySame() is removed. That seems like a good idea.

Re: WIP: Covering + unique indexes.

On Sat, Apr 7, 2018 at 5:48 AM, Teodor Sigaev wrote: > On close look, bts_btentry.ip_posid is not used anymore, I change > bts_btentry type to BlockNumber. As result, BTEntrySame() is removed. That seems like a good idea. > I'm not very happy with massive usage of >

Re: WIP: Covering + unique indexes.

I didn't like rel.h being included in itup.h. Do you really need a Relation as argument to index_truncate_tuple? It looks to me like you could pass the tupledesc instead; indnatts could be passed as a separate argument instead of IndexRelationGetNumberOfAttributes. -- Álvaro Herrera

Re: WIP: Covering + unique indexes. (the good and the bad)

On 2018-04-07 14:27, Alexander Korotkov wrote: On Sat, Apr 7, 2018 at 2:57 PM, Erik Rijkers wrote: On 2018-04-06 20:08, Alexander Korotkov wrote: [0001-Covering-v15.patch] After some more testing I notice there is also a down-side/slow-down to this patch that is not so bad

Re: WIP: Covering + unique indexes. (the good and the bad)

On Sat, Apr 7, 2018 at 2:57 PM, Erik Rijkers wrote: > On 2018-04-06 20:08, Alexander Korotkov wrote: > >> >> [0001-Covering-v15.patch] >> >> > After some more testing I notice there is also a down-side/slow-down to > this patch that is not so bad but more than negligible, and I

Re: WIP: Covering + unique indexes. (the good and the bad)

Thank you!   create unique index ${t}uniqueinclude_idx on $t using btree (c1, c2) include (c3, c4); or for HEAD, just:   create unique index ${t}unique_idx on $t using btree (c1, c2); -- explain analyze select c1, c2 from nt0___1 where c1 < 1 -- explain analyze select c1, c2

Re: WIP: Covering + unique indexes. (the good and the bad)

On 2018-04-06 20:08, Alexander Korotkov wrote: [0001-Covering-v15.patch] After some more testing I notice there is also a down-side/slow-down to this patch that is not so bad but more than negligible, and I don't think it has been mentioned (but I may have missed something in this thread

Re: WIP: Covering + unique indexes.

On Fri, Apr 6, 2018 at 11:08 AM, Alexander Korotkov wrote: > OK, incorporated into v15. I've also added sentence about pg_upgrade > to the commit message. I will summarize my feelings on this patch. I endorse committing the patch, because I think that the benefits of

Re: WIP: Covering + unique indexes.

On Fri, Apr 6, 2018 at 10:33 AM, Alexander Korotkov wrote: > Thinking about that again, I found that we should relax our requirements to > "minus infinity" items, because pg_upgraded indexes doesn't have any > special bits set for those items. > > What do you think

Re: WIP: Covering + unique indexes.

On Fri, Apr 6, 2018 at 8:22 PM, Peter Geoghegan wrote: > On Fri, Apr 6, 2018 at 10:20 AM, Teodor Sigaev wrote: > > As far I can see, there is no any on-disk representation differece for > > *existing* indexes. So, pg_upgrade is not need here and there isn't any >

Re: WIP: Covering + unique indexes.

On Fri, Apr 6, 2018 at 10:20 AM, Teodor Sigaev wrote: > As far I can see, there is no any on-disk representation differece for > *existing* indexes. So, pg_upgrade is not need here and there isn't any new > code to support "on-fly" modification. Am I right? Yes. I'm going to

Re: WIP: Covering + unique indexes.

As far I can see, there is no any on-disk representation differece for *existing* indexes. So, pg_upgrade is not need here and there isn't any new code to support "on-fly" modification. Am I right? -- Teodor Sigaev E-mail: teo...@sigaev.ru

Re: WIP: Covering + unique indexes.

On Thu, Apr 5, 2018 at 7:59 AM, Alexander Korotkov wrote: >> * btree_xlog_split() still has this code: > Right, I think there is absolutely no need in this code. It's removed in > the attached patchset. I'm now a bit nervous about always logging the high key, since

Re: WIP: Covering + unique indexes.

On Thu, Apr 5, 2018 at 5:02 PM, Erik Rijkers wrote: > On 2018-04-05 00:09, Alexander Korotkov wrote: > >> Thank you for review! Revised patchset is attached. >> [0001-Covering-core-v12.patch] >> [0002-Covering-btree-v12.patch] >> [0003-Covering-amcheck-v12.patch] >>

Re: WIP: Covering + unique indexes.

On 2018-04-05 00:09, Alexander Korotkov wrote: Hi! Thank you for review! Revised patchset is attached. [0001-Covering-core-v12.patch] [0002-Covering-btree-v12.patch] [0003-Covering-amcheck-v12.patch] [0004-Covering-natts-v12.patch] Really nice performance gains. I read through the docs and

Re: WIP: Covering + unique indexes.

On Wed, Apr 4, 2018 at 3:09 PM, Alexander Korotkov wrote: > Thank you for review! Revised patchset is attached. Cool. * btree_xlog_split() still has this code: /* * On leaf level, the high key of the left page is equal to the first key * on the right

Re: WIP: Covering + unique indexes.

On Tue, Apr 3, 2018 at 7:02 AM, Alexander Korotkov wrote: > Great, I'm looking forward your feedback. I took a look at V11 (0001-Covering-core-v11.patch, 0002-Covering-btree-v11.patch, 0003-Covering-amcheck-v11.patch, 0004-Covering-natts-v11.patch) today. * What's a

Re: WIP: Covering + unique indexes.

On Tue, Apr 3, 2018 at 7:02 AM, Peter Geoghegan wrote: > On Mon, Apr 2, 2018 at 4:27 PM, Alexander Korotkov > wrote: > > I thought abut that another time and I decided that it would be safer > > to use 13th bit in index tuple flags. There are already

Re: WIP: Covering + unique indexes.

On Mon, Apr 2, 2018 at 4:27 PM, Alexander Korotkov wrote: > I thought abut that another time and I decided that it would be safer > to use 13th bit in index tuple flags. There are already attempt to > use whole 6 bytes of tid for not heap pointer information [1].

Re: WIP: Covering + unique indexes.

On Sun, Apr 1, 2018 at 10:09 AM, Alexander Korotkov wrote: >> So? GIN doesn't have the same legacy at all. The GIN posting lists >> *don't* have regular heap TID pointers at all. They started out >> without them, and still don't have them. > > > Yes, GIN never stored

Re: WIP: Covering + unique indexes.

On Fri, Mar 30, 2018 at 6:24 AM, Alexander Korotkov wrote: >> With an extreme enough case, this could result in a failure to find a >> split point. Or at least, if that isn't true then it's not clear why, >> and I think it needs to be explained. > > > I don't think this

Re: WIP: Covering + unique indexes.

On Fri, Mar 30, 2018 at 10:39 PM, Peter Geoghegan wrote: > It's safe, although I admit that that's a bit hard to see. > Specifically, look at this code in _bt_insert_parent(): > > /* > * Find the parent buffer and get the parent page. > * > * Oops

Re: WIP: Covering + unique indexes.

On Fri, Mar 30, 2018 at 4:08 PM, Alexander Korotkov wrote: >> I'll try it. But I'm afraid that it's not as easy as you expect. > > > So, I have some implementation of storage of number of attributes inside > index tuple itself. I made it as additional patch on top of

Re: WIP: Covering + unique indexes.

On Wed, Mar 28, 2018 at 7:59 AM, Anastasia Lubennikova wrote: > Here is the new version of the patch set. > All patches are rebased to apply without conflicts. > > Besides, they contain following fixes: > - pg_dump bug is fixed > - index_truncate_tuple() now has 3rd

Re: WIP: Covering + unique indexes.

On 1/25/18 23:19, Thomas Munro wrote: > + PRIMARY KEY ( class="parameter">column_name [, ... ] ) class="parameter">index_parameters INCLUDE > (column_name [, > ...]) | > > I hadn't seen that use of "" before. Almost everywhere else > we use explicit [ and ] characters, but I see that there

Re: WIP: Covering + unique indexes.

On 2018-03-28 16:59, Anastasia Lubennikova wrote: Here is the new version of the patch set. I can't get these to apply: patch -b -l -F 25 -p 1 < /home/aardvark/download/pgpatches/0110/covering_indexes/20180328/0001-Covering-core-v8.patch 1 out of 19 hunks FAILED -- saving rejects to file

Re: WIP: Covering + unique indexes.

On Tue, Mar 27, 2018 at 10:14 AM, Teodor Sigaev wrote: >> b) I don't like an idea to limiting usage of that field if we can do not >> that. Future usage could use it, for example, for different compression >> technics or something else.Or even removing t_tid from inner tuples to

Re: WIP: Covering + unique indexes.

On Tue, Mar 27, 2018 at 10:07 AM, Teodor Sigaev wrote: > Storing number of attributes in now unused t_tid seems to me not so good > idea. a) it could (and suppose, should) separate patch, at least it's not > directly connected to covering patch, it could be added even before

Re: WIP: Covering + unique indexes.

b) I don't like an idea to limiting usage of that field if we can do not that. Future usage could use it, for example, for different compression technics or something else.Or even removing t_tid from inner tuples to save 2 bytes in IndexTupleData. Of course, I remember about aligment, but it

Re: WIP: Covering + unique indexes.

On Mon, Mar 26, 2018 at 3:10 AM, Alexander Korotkov wrote: > So, as I get you're proposing to introduce INDEX_ALT_TID_MASK flag > which would indicate that we're storing something special in the t_tid > offset. And that should help us not only for covering indexes, but

Re: Re: WIP: Covering + unique indexes.

On 3/26/18 6:10 AM, Alexander Korotkov wrote: > > So, as I get you're proposing to introduce INDEX_ALT_TID_MASK flag > which would indicate that we're storing something special in the t_tid > offset.  And that should help us not only for covering indexes, but also for > further btree enhancements

Re: WIP: Covering + unique indexes.

On Sun, Mar 25, 2018 at 1:47 AM, Peter Geoghegan wrote: > I was going to say that you could just treat the low bit in the t_tid > offset as representing "see catalog entry". My first idea was that > nothing would have to change about the existing format, since internal > page items

Re: WIP: Covering + unique indexes.

On Sat, Mar 24, 2018 at 12:39 PM, Alexander Korotkov wrote: > +1, putting "nattributes" to argument of index_truncate_tuple() would > make this function way more universal. Great. > Originally that code was written by Teodor, but I also put my hands there. > In GIN

Re: WIP: Covering + unique indexes.

On Sat, Mar 24, 2018 at 5:21 AM, Peter Geoghegan wrote: > On Thu, Mar 22, 2018 at 8:23 AM, Alexander Korotkov > wrote: > >> * There is minor formatting issue in this part of code. Some spaces > need > >> to be replaced with tabs. > >> +IndexTuple > >>

Re: WIP: Covering + unique indexes.

On Thu, Mar 22, 2018 at 8:23 AM, Alexander Korotkov wrote: >> * There is minor formatting issue in this part of code. Some spaces need >> to be replaced with tabs. >> +IndexTuple >> +index_truncate_tuple(Relation idxrel, IndexTuple olditup) >> +{ >> + TupleDesc

Re: WIP: Covering + unique indexes.

On Wed, Mar 21, 2018 at 9:51 PM, Alexander Korotkov < a.korot...@postgrespro.ru> wrote: > On Thu, Mar 8, 2018 at 7:13 PM, Anastasia Lubennikova < > a.lubennik...@postgrespro.ru> wrote: > >> 06.03.2018 11:52, Thomas Munro: >> >>> On Wed, Jan 31, 2018 at 3:09 AM, Anastasia Lubennikova >>>

Re: WIP: Covering + unique indexes.

On Thu, Mar 8, 2018 at 7:13 PM, Anastasia Lubennikova < a.lubennik...@postgrespro.ru> wrote: > 06.03.2018 11:52, Thomas Munro: > >> On Wed, Jan 31, 2018 at 3:09 AM, Anastasia Lubennikova >> wrote: >> >>> Thank you for reviewing. All mentioned issues are fixed. >>>

Re: WIP: Covering + unique indexes.

On Wed, Jan 31, 2018 at 3:09 AM, Anastasia Lubennikova wrote: > Thank you for reviewing. All mentioned issues are fixed. == Applying patch 0002-covering-btree_v4.patch... 1 out of 1 hunk FAILED -- saving rejects to file src/backend/access/nbtree/README.rej 1 out of

Re: WIP: Covering + unique indexes.

On Fri, Jan 26, 2018 at 3:01 AM, Anastasia Lubennikova wrote: > Thanks for the reminder. Rebased patches are attached. This is a really cool and also difficult feature. Thanks for working on it! Here are a couple of quick comments on the documentation, since I

Re: WIP: Covering + unique indexes.

I feel sorry for the noise, switching this patch there and back. But the patch needs rebase again. It still applies with -3, but do not compile anymore. Best regards, Andrey Borodin. The new status of this patch is: Waiting on Author