Re: [HACKERS] WIP: Covering + unique indexes.

Hi! +1 for pushing this. I'm really looking forward to see this in 11. > 31 окт. 2017 г., в 13:21, Anastasia Lubennikova > написал(а): > > Updated version is attached. It applies to the commit > e4fbf22831c2bbcf032ee60a327b871d2364b3f5. > The first patch patch contains changes in general index

Re: [HACKERS] WIP: Covering + unique indexes.

On 4/4/17 2:47 PM, Peter Geoghegan wrote: > > At the very least, you should change comments to note the issue. I > think it's highly unlikely that this could ever result in a failure to > find a split point, which there are many defenses against already, but > I think I would find that difficult t

Re: [HACKERS] WIP: Covering + unique indexes.

On Tue, Apr 4, 2017 at 3:07 AM, Anastasia Lubennikova wrote: >> * I think that we should store this (the number of attributes), and >> use it directly when comparing, per my remarks to Tom over on that >> other thread. We should also use the free bit within >> IndexTupleData.t_info, to indicate th

Re: [HACKERS] WIP: Covering + unique indexes.

01.04.2017 02:31, Peter Geoghegan: * index_truncate_tuple() should have as an argument the number of attributes. No need to "#include utils/rel.h" that way. Will fix. * I think that we should store this (the number of attributes), and use it directly when comparing, per my remarks to Tom over

Re: [HACKERS] WIP: Covering + unique indexes.

On Thu, Mar 30, 2017 at 8:26 AM, Teodor Sigaev wrote: > Any objection from reviewers to push both patches? I object. Unfortunately, it seems very unlikely that we'll be able to get the patch into shape in the allotted time before feature-freeze, even with the 1 week extension. -- Peter Geogheg

Re: [HACKERS] WIP: Covering + unique indexes.

On Fri, Mar 31, 2017 at 4:31 PM, Peter Geoghegan wrote: > That's all I have for now. Maybe I can look again later, or tomorrow. I took another look, this time at code used during CREATE INDEX. More feedback: * I see no reason to expose _bt_pgaddtup() (to modify it to not be static, so it can be

Re: [HACKERS] WIP: Covering + unique indexes.

I had a quick look at this on the flight back from PGConf.US. On Fri, Mar 31, 2017 at 10:40 AM, Anastasia Lubennikova wrote: > But I haven't considered the possibility of index_form_tuple() failure. > Fixed in this version of the patch. Now it creates a copy of tupledesc to > pass it to index_for

Re: [HACKERS] WIP: Covering + unique indexes.

31.03.2017 20:57, Robert Haas: On Fri, Mar 31, 2017 at 1:40 PM, Anastasia Lubennikova wrote: First of all, I want to thank you and Robert for reviewing this patch. Your expertise in postgres subsystems is really necessary for features like this. I just wonder, why don't you share your thoughts

Re: [HACKERS] WIP: Covering + unique indexes.

31.03.2017 20:47, Andres Freund: Maybe it would be better to modify index_form_tuple() to accept a new argument with a number of attributes, then you can just Assert that this number is never higher than the number of attributes in the TupleDesc. Good point. I agree that this function is a bit s

Re: [HACKERS] WIP: Covering + unique indexes.

On Fri, Mar 31, 2017 at 1:40 PM, Anastasia Lubennikova wrote: > First of all, I want to thank you and Robert for reviewing this patch. > Your expertise in postgres subsystems is really necessary for features like > this. > I just wonder, why don't you share your thoughts and doubts till the "last

Re: [HACKERS] WIP: Covering + unique indexes.

On 2017-03-31 20:40:59 +0300, Anastasia Lubennikova wrote: > 30.03.2017 22:11, Andres Freund > > Any objection from reviewers to push both patches? > > First of all, I want to thank you and Robert for reviewing this patch. > Your expertise in postgres subsystems is really necessary for features li

Re: [HACKERS] WIP: Covering + unique indexes.

On Thu, Mar 30, 2017 at 5:22 PM, Anastasia Lubennikova wrote: > Well, > I don't know how can we estimate the quality of the review or testing. > The patch was reviewed by many people. > Here are those who marked themselves as reviewers on this and previous > committfests: Stephen Frost (sfrost), A

Re: [HACKERS] WIP: Covering + unique indexes.

30.03.2017 19:49, Robert Haas: On Thu, Mar 30, 2017 at 11:26 AM, Teodor Sigaev wrote: I had a look on patch and played with it, seems, it looks fine. I splitted it to two patches: core changes (+bloom index fix) and btree itself. All docs are left in first patch - I'm too lazy to rewrite docume

Re: [HACKERS] WIP: Covering + unique indexes.

Hi Robert, > Has anybody done some testing of this patch with the WAL consistency > checker? Like, create some tables with indexes that have INCLUDE > columns, set up a standby, enable consistency checking, pound the > master, and see if the standby bails? I've decided to run such a test. It loo

Re: [HACKERS] WIP: Covering + unique indexes.

On 2017-03-30 18:26:05 +0300, Teodor Sigaev wrote: > Any objection from reviewers to push both patches? > diff --git a/contrib/bloom/blutils.c b/contrib/bloom/blutils.c > index f2eda67..59029b9 100644 > --- a/contrib/bloom/blutils.c > +++ b/contrib/bloom/blutils.c > @@ -120,6 +120,7 @@ blhandler(

Re: [HACKERS] WIP: Covering + unique indexes.

On Thu, Mar 30, 2017 at 11:26 AM, Teodor Sigaev wrote: > I had a look on patch and played with it, seems, it looks fine. I splitted > it to two patches: core changes (+bloom index fix) and btree itself. All > docs are left in first patch - I'm too lazy to rewrite documentation which > is changed i

Re: [HACKERS] WIP: Covering + unique indexes.

Hi Teodor, > I had a look on patch and played with it, seems, it looks fine. I splitted > it to two patches: core changes (+bloom index fix) and btree itself. All > docs are left in first patch - I'm too lazy to rewrite documentation which > is changed in second patch. > Any objection from reviewe

Re: [HACKERS] WIP: Covering + unique indexes.

I had a look on patch and played with it, seems, it looks fine. I splitted it to two patches: core changes (+bloom index fix) and btree itself. All docs are left in first patch - I'm too lazy to rewrite documentation which is changed in second patch. Any objection from reviewers to push both pa

Re: [HACKERS] WIP: Covering + unique indexes.

- IDENTITY_P IF_P ILIKE IMMEDIATE IMMUTABLE IMPLICIT_P IMPORT_P IN_P + IDENTITY_P IF_P ILIKE IMMEDIATE IMMUTABLE IMPLICIT_P IMPORT_P IN_P INCLUDE I think your syntax would read no worse, possibly even better, if you just used the existing INCLUDING keyword. It was a discussion in thi

Re: [HACKERS] WIP: Covering + unique indexes.

The following review has been posted through the commitfest application: make installcheck-world: tested, passed Implements feature: tested, passed Spec compliant: tested, passed Documentation:tested, passed This patch looks good to me. As I understand we have both a c

Re: [HACKERS] WIP: Covering + unique indexes.

Patch rebased to the current master is in attachments. -- Anastasia Lubennikova Postgres Professional: http://www.postgrespro.com The Russian Postgres Company commit 497d52b713dd8f926b465ddf22f21db7229b12e3 Author: Anastasia Date: Tue Mar 21 12:58:13 2017 +0300 include_columns_10.0_v4.pa

Re: [HACKERS] WIP: Covering + unique indexes.

On 2/16/17 08:13, Anastasia Lubennikova wrote: > @@ -629,7 +630,7 @@ static Node *makeRecursiveViewSelect(char *relname, List > *aliases, Node *query); > > HANDLER HAVING HEADER_P HOLD HOUR_P > > - IDENTITY_P IF_P ILIKE IMMEDIATE IMMUTABLE IMPLICIT_P IMPORT_P IN_P > + IDENTITY_P

Re: [HACKERS] WIP: Covering + unique indexes.

On Thu, Feb 16, 2017 at 6:43 PM, Anastasia Lubennikova wrote: > 14.02.2017 15:46, Amit Kapila: > > >> 4. >> + IDENTITY_P IF_P ILIKE IMMEDIATE IMMUTABLE IMPLICIT_P IMPORT_P IN_P >> INCLUDE >>INCLUDING INCREMENT INDEX INDEXES INHERIT INHERITS INITIALLY INLINE_P >>INNER_P INOUT INPUT_P INSENS

Re: [HACKERS] WIP: Covering + unique indexes.

On Mon, Jan 9, 2017 at 8:32 PM, Anastasia Lubennikova wrote: > Updated version of the patch is attached. Besides code itself, it contains > new regression test, > documentation updates and a paragraph in nbtree/README. > The latest patch doesn't apply cleanly. Few assorted comments: 1. @@ -4806,

Re: [HACKERS] WIP: Covering + unique indexes.

On 2017-01-09 16:02, Anastasia Lubennikova wrote: include_columns_10.0_v1.patch The patch applies, compiles, and make check is OK. It yields nice perfomance gains and I haven't been able to break anything (yet). Some edits of the sgml-changes are attached. Thank you for this very useful i

Re: [HACKERS] WIP: Covering + unique indexes.

On Sat, Nov 19, 2016 at 8:38 AM, Peter Eisentraut < peter.eisentr...@2ndquadrant.com> wrote: > On 10/4/16 10:47 AM, Anastasia Lubennikova wrote: > > 03.10.2016 15:29, Anastasia Lubennikova: > >> 03.10.2016 05:22, Michael Paquier: > >>> On Tue, Sep 27, 2016 at 12:17 AM, Anastasia Lubennikova > >>>

Re: [HACKERS] WIP: Covering + unique indexes.

On 10/4/16 10:47 AM, Anastasia Lubennikova wrote: > 03.10.2016 15:29, Anastasia Lubennikova: >> 03.10.2016 05:22, Michael Paquier: >>> On Tue, Sep 27, 2016 at 12:17 AM, Anastasia Lubennikova >>> wrote: Ok, I'll write it in a few days. >>> Marked as returned with feedback per last emails excha

Re: [HACKERS] WIP: Covering + unique indexes

Anastasia, et al, This is a review of including_columns_9.7_v5.patch. I looked through the commit fest list and this patch was interesting and I wanted to try it. I have used include columns on Microsoft SQL Server; DB2 for Linux, Unix, Windows; and DB2 for z/OS. After reading the e-mail disc

Re: [HACKERS] WIP: Covering + unique indexes.

Robert Haas writes: > On Wed, Oct 5, 2016 at 9:04 AM, Amit Kapila wrote: >> Okay, but in that case I think we don't need to store including >> columns in non-leaf pages to get the exact ordering. As mentioned >> upthread, we can use truncated scan key to reach to leaf level and >> then use the c

Re: [HACKERS] WIP: Covering + unique indexes.

On Wed, Oct 5, 2016 at 9:04 AM, Amit Kapila wrote: > Okay, but in that case I think we don't need to store including > columns in non-leaf pages to get the exact ordering. As mentioned > upthread, we can use truncated scan key to reach to leaf level and > then use the complete key to find the exa

Re: [HACKERS] WIP: Covering + unique indexes.

On Tue, Oct 4, 2016 at 7:50 PM, Robert Haas wrote: > On Tue, Oct 4, 2016 at 9:20 AM, Amit Kapila wrote: I'd say that the reason for not using included columns in any operations which require comparisons, is that they don't have opclass. Let's go back to the example of points.

Re: [HACKERS] WIP: Covering + unique indexes.

03.10.2016 15:29, Anastasia Lubennikova: 03.10.2016 05:22, Michael Paquier: On Tue, Sep 27, 2016 at 12:17 AM, Anastasia Lubennikova wrote: Ok, I'll write it in a few days. Marked as returned with feedback per last emails exchanged. The only complaint about this patch was a lack of README, w

Re: [HACKERS] WIP: Covering + unique indexes.

On Tue, Oct 4, 2016 at 9:20 AM, Amit Kapila wrote: >>> I'd say that the reason for not using included columns in any >>> operations which require comparisons, is that they don't have opclass. >>> Let's go back to the example of points. >>> This data type don't have any opclass for B-tree, because

Re: [HACKERS] WIP: Covering + unique indexes.

On Tue, Sep 27, 2016 at 7:51 PM, Robert Haas wrote: > On Mon, Sep 26, 2016 at 11:17 AM, Anastasia Lubennikova > wrote: >>> Is there any fundamental problem in storing them in ordered way? I >>> mean to say, you need to anyway store all the column values on leaf >>> page, so why can't we find the

Re: [HACKERS] WIP: Covering + unique indexes.

03.10.2016 05:22, Michael Paquier: On Tue, Sep 27, 2016 at 12:17 AM, Anastasia Lubennikova wrote: Ok, I'll write it in a few days. Marked as returned with feedback per last emails exchanged. The only complaint about this patch was a lack of README, which is fixed now (see the attachment). So

Re: [HACKERS] WIP: Covering + unique indexes.

On Tue, Sep 27, 2016 at 12:17 AM, Anastasia Lubennikova wrote: > Ok, I'll write it in a few days. Marked as returned with feedback per last emails exchanged. -- Michael -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postg

Re: [HACKERS] WIP: Covering + unique indexes.

On Mon, Sep 26, 2016 at 11:17 AM, Anastasia Lubennikova wrote: >> Is there any fundamental problem in storing them in ordered way? I >> mean to say, you need to anyway store all the column values on leaf >> page, so why can't we find the exact location for the complete key. >> Basically use trunc

Re: [HACKERS] WIP: Covering + unique indexes.

24.09.2016 15:36, Amit Kapila: On Wed, Sep 21, 2016 at 6:51 PM, Anastasia Lubennikova wrote: 20.09.2016 08:21, Amit Kapila: On Tue, Sep 6, 2016 at 10:18 PM, Anastasia Lubennikova wrote: 28.08.2016 09:13, Amit Kapila: The problem seems really tricky, but the answer is simple. We store incl

Re: [HACKERS] WIP: Covering + unique indexes.

On Wed, Sep 21, 2016 at 6:51 PM, Anastasia Lubennikova wrote: > 20.09.2016 08:21, Amit Kapila: > > On Tue, Sep 6, 2016 at 10:18 PM, Anastasia Lubennikova > wrote: > > 28.08.2016 09:13, Amit Kapila: > > > The problem seems really tricky, but the answer is simple. > We store included columns unorde

Re: [HACKERS] WIP: Covering + unique indexes.

On Tue, Sep 20, 2016 at 10:51 AM, Amit Kapila wrote: > On Tue, Sep 6, 2016 at 10:18 PM, Anastasia Lubennikova > wrote: >> 28.08.2016 09:13, Amit Kapila: >> >> On Mon, Aug 15, 2016 at 8:15 PM, Anastasia Lubennikova >> wrote: >> >> >> So the patch is correct. >> We can go further and remove this i

Re: [HACKERS] WIP: Covering + unique indexes.

On Tue, Sep 6, 2016 at 10:18 PM, Anastasia Lubennikova wrote: > 28.08.2016 09:13, Amit Kapila: > > On Mon, Aug 15, 2016 at 8:15 PM, Anastasia Lubennikova > wrote: > > > So the patch is correct. > We can go further and remove this index_truncate_tuple() call, because > the first key of any inner (

Re: [HACKERS] WIP: Covering + unique indexes.

One more update. I added ORDER BY clause to regression tests. It was done as a separate bugfix patch by Tom Lane some time ago, but it definitely should be included into the patch. -- Anastasia Lubennikova Postgres Professional: http://www.postgrespro.com The Russian Postgres Company diff --git

Re: [HACKERS] WIP: Covering + unique indexes.

28.08.2016 09:13, Amit Kapila: On Mon, Aug 15, 2016 at 8:15 PM, Anastasia Lubennikova wrote: @@ -590,7 +622,14 @@ _bt_buildadd(BTWriteState *wstate, BTPageState *state, IndexTuple itup) if (last_off == P_HIKEY) { Assert(state->btps_minkey == NULL); - state->btps_minkey = CopyIndexTuple

Re: [HACKERS] WIP: Covering + unique indexes.

On Mon, Aug 15, 2016 at 8:15 PM, Anastasia Lubennikova wrote: @@ -590,7 +622,14 @@ _bt_buildadd(BTWriteState *wstate, BTPageState *state, IndexTuple itup) if (last_off == P_HIKEY) { Assert(state->btps_minkey == NULL); - state->btps_minkey = CopyIndexTuple(itup); + /* + * Truncate the tuple t

Re: [HACKERS] WIP: Covering + unique indexes.

> That was a bug caused by high key truncation, that occurs when index has more > than 3 levels. Fixed. Affirmative. I've tested index construction with 100M rows and subsequent execution of select queries using index, works fine. Best regards, Andrey Borodin, Octonica & Ural Federal University.

Re: [HACKERS] WIP: Covering + unique indexes.

14.08.2016 20:11, Andrey Borodin: The following review has been posted through the commitfest application: make installcheck-world: tested, passed Implements feature: tested, failed Spec compliant: tested, passed Documentation:tested, passed Hi hackers! I've read th

Re: [HACKERS] WIP: Covering + unique indexes.

The following review has been posted through the commitfest application: make installcheck-world: tested, passed Implements feature: tested, failed Spec compliant: tested, passed Documentation:tested, passed Hi hackers! I've read the patch and here is my code review.

Re: [HACKERS] WIP: Covering + unique indexes.

On Wed, Apr 27, 2016 at 5:47 PM, David Steele wrote: > On 4/27/16 5:08 PM, Peter Geoghegan wrote: >> So, in case it needs to be >> said, I'll say it: You've chosen a very ambitious set of projects to >> work on, by any standard. I think it's a good thing that you've been >> ambitious, and I don't

Re: [HACKERS] WIP: Covering + unique indexes.

On 4/27/16 5:08 PM, Peter Geoghegan wrote: > So, in case it needs to be > said, I'll say it: You've chosen a very ambitious set of projects to > work on, by any standard. I think it's a good thing that you've been > ambitious, and I don't suggest changing that, since I think that you > have commen

Re: [HACKERS] WIP: Covering + unique indexes.

On Tue, Apr 12, 2016 at 9:14 AM, Anastasia Lubennikova wrote: > Sooner or later, I'd like to see this patch finished. Me, too. > For now, it has two complaints: > - support of expressions as included columns. > Frankly, I don't understand, why it's a problem of the patch. > The patch is already

Re: [HACKERS] WIP: Covering + unique indexes.

Attached version has fix of pg_dump suggested by Stephen Frost in -committers thread. http://postgresql.nabble.com/pgsql-CREATE-INDEX-INCLUDING-column-td5897653.html Sooner or later, I'd like to see this patch fin

Re: [HACKERS] WIP: Covering + unique indexes.

08.04.2016 15:45, Anastasia Lubennikova: 08.04.2016 15:06, Teodor Sigaev: On Wed, Apr 6, 2016 at 1:50 PM, Peter Geoghegan wrote: Personally, I like documenting assertions, and will sometimes write assertions that the compiler could easily optimize away. Maybe going *that* far is more a matter

Re: [HACKERS] WIP: Covering + unique indexes.

08.04.2016 15:06, Teodor Sigaev: On Wed, Apr 6, 2016 at 1:50 PM, Peter Geoghegan wrote: Personally, I like documenting assertions, and will sometimes write assertions that the compiler could easily optimize away. Maybe going *that* far is more a matter of personal style, but I think an assertio

Re: [HACKERS] WIP: Covering + unique indexes.

On Wed, Apr 6, 2016 at 1:50 PM, Peter Geoghegan wrote: Personally, I like documenting assertions, and will sometimes write assertions that the compiler could easily optimize away. Maybe going *that* far is more a matter of personal style, but I think an assertion about the new index tuple size b

Re: [HACKERS] WIP: Covering + unique indexes.

06.04.2016 23:52, Peter Geoghegan: On Wed, Apr 6, 2016 at 1:50 PM, Peter Geoghegan wrote: Personally, I like documenting assertions, and will sometimes write assertions that the compiler could easily optimize away. Maybe going *that* far is more a matter of personal style, but I think an assert

Re: [HACKERS] WIP: Covering + unique indexes.

On Wed, Apr 6, 2016 at 1:50 PM, Peter Geoghegan wrote: > Personally, I like documenting assertions, and will sometimes write > assertions that the compiler could easily optimize away. Maybe going > *that* far is more a matter of personal style, but I think an > assertion about the new index tuple

Re: [HACKERS] WIP: Covering + unique indexes.

On Wed, Apr 6, 2016 at 6:15 AM, Anastasia Lubennikova wrote: >> * I would like to see index_reform_tuple() assert that the new, >> truncated index tuple is definitely <= the original (I worry about the >> 1/3 page restriction issue). Maybe you should also change the name of >> index_reform_tuple()

Re: [HACKERS] WIP: Covering + unique indexes.

06.04.2016 16:15, Anastasia Lubennikova : 06.04.2016 03:05, Peter Geoghegan: * There is some stray whitespace within RelationGetIndexAttrBitmap(). I think you should have updated it with code, though. I don't think it's necessary for HOT updates to work, but I think it could be necessary so that

Re: [HACKERS] WIP: Covering + unique indexes.

06.04.2016 03:05, Peter Geoghegan: On Tue, Apr 5, 2016 at 1:31 PM, Peter Geoghegan wrote: My new understanding: The extra "included" columns are stored in the index, but do not affect its sort order at all. They are no more part of the key than, say, the heap TID that the key points to. They ar

Re: [HACKERS] WIP: Covering + unique indexes.

On Tue, Apr 5, 2016 at 1:31 PM, Peter Geoghegan wrote: > My new understanding: The extra "included" columns are stored in the > index, but do not affect its sort order at all. They are no more part > of the key than, say, the heap TID that the key points to. They are > just "payload". Noticed a f

Re: [HACKERS] WIP: Covering + unique indexes.

On Tue, Apr 5, 2016 at 7:56 AM, Anastasia Lubennikova wrote: > I would say, this is changed, but it doesn't matter. Actually, I would now say that it hasn't really changed (see below), based on my new understanding. The *choice* to go on one page or the other still exists. > Performing any searc

Re: [HACKERS] WIP: Covering + unique indexes.

05.04.2016 01:48, Peter Geoghegan : On Mon, Mar 21, 2016 at 9:53 AM, Anastasia Lubennikova wrote: It's a bit more complicated to add it into index creation algorithm. There's a trick with a "high key". /* * We copy the last item on the page into the new page, and then

Re: [HACKERS] WIP: Covering + unique indexes.

On Mon, Mar 21, 2016 at 9:53 AM, Anastasia Lubennikova wrote: > Thanks to David, > I've missed these letters at first. > I'll answer here. Sorry about using the wrong thread. > I agree that _bt_insertonpg() is not right for truncation. Cool. > It's a bit more complicated to add it into index c

Re: [HACKERS] WIP: Covering + unique indexes.

Peter Geoghegan writes: > On Mon, Apr 4, 2016 at 7:14 AM, Teodor Sigaev wrote: >> Are there any objectins on it? I'm planning to look closely today or >> tommorrow and commit it. > I object to committing the patch in that time frame. I'm looking at it again. Since it's a rather complex patch, p

Re: [HACKERS] WIP: Covering + unique indexes.

On Mon, Apr 4, 2016 at 7:14 AM, Teodor Sigaev wrote: > Are there any objectins on it? I'm planning to look closely today or > tommorrow and commit it. I object to committing the patch in that time frame. I'm looking at it again. -- Peter Geoghegan -- Sent via pgsql-hackers mailing list (pgs

Re: [HACKERS] WIP: Covering + unique indexes.

It seems to me that the patch is completed. Except, maybe, grammar check of comments and documentation. Looking forward to your review. Are there any objectins on it? I'm planning to look closely today or tommorrow and commit it. -- Teodor Sigaev E-mail: teo..

Re: [HACKERS] WIP: Covering + unique indexes.

21.03.2016 19:53, Anastasia Lubennikova: 19.03.2016 08:00, Peter Geoghegan: On Fri, Mar 18, 2016 at 5:15 AM, David Steele wrote: It looks like this patch should be marked "needs review" and I have done so. Uh, no it shouldn't. I've posted an extensive review on the original design thread. See

Re: [HACKERS] WIP: Covering + unique indexes.

19.03.2016 08:00, Peter Geoghegan: On Fri, Mar 18, 2016 at 5:15 AM, David Steele wrote: It looks like this patch should be marked "needs review" and I have done so. Uh, no it shouldn't. I've posted an extensive review on the original design thread. See CF entry: https://commitfest.postgresql.

Re: [HACKERS] WIP: Covering + unique indexes.

On 3/14/16 9:57 AM, Anastasia Lubennikova wrote: > New version of the patch implements pg_dump well. > Documentation related to constraints is updated. > > I hope, that patch is in a good shape now. It looks like this patch should be marked "needs review" and I have done so. -- -David da...@pg

Re: [HACKERS] WIP: Covering + unique indexes.

On Fri, Mar 18, 2016 at 5:15 AM, David Steele wrote: > It looks like this patch should be marked "needs review" and I have done so. Uh, no it shouldn't. I've posted an extensive review on the original design thread. See CF entry: https://commitfest.postgresql.org/9/433/ Marked "Waiting on Autho

Re: [HACKERS]WIP: Covering + unique indexes.

02.03.2016 08:50, Michael Paquier: On Wed, Mar 2, 2016 at 2:10 AM, Anastasia Lubennikova wrote: 01.03.2016 19:55, Anastasia Lubennikova: It is not the final version, because it breaks pg_dump for previous versions. I need some help from hackers here. pgdump. line 5466 if (fout->remoteVersion >

Re: [HACKERS]WIP: Covering + unique indexes.

On Wed, Mar 2, 2016 at 2:10 AM, Anastasia Lubennikova wrote: > 01.03.2016 19:55, Anastasia Lubennikova: >> It is not the final version, because it breaks pg_dump for previous >> versions. I need some help from hackers here. >> pgdump. line 5466 >> if (fout->remoteVersion >= 90400) >> >> What does

Re: [HACKERS]WIP: Covering + unique indexes.

01.03.2016 19:55, Anastasia Lubennikova: 29.02.2016 18:17, Anastasia Lubennikova: 25.02.2016 21:39, Jeff Janes: As promised, here's the new version of the patch "including_columns_4.0". I fixed all issues except some points mentioned below. Thanks for the update patch. I get a compiler warn

Re: [HACKERS]WIP: Covering + unique indexes.

29.02.2016 18:17, Anastasia Lubennikova: 25.02.2016 21:39, Jeff Janes: As promised, here's the new version of the patch "including_columns_4.0". I fixed all issues except some points mentioned below. Thanks for the update patch. I get a compiler warning: genam.c: In function 'BuildIndexValu

Re: [HACKERS]WIP: Covering + unique indexes.

25.02.2016 21:39, Jeff Janes: As promised, here's the new version of the patch "including_columns_4.0". I fixed all issues except some points mentioned below. Thanks for the update patch. I get a compiler warning: genam.c: In function 'BuildIndexValueDescription': genam.c:259: warning: unused

Re: [HACKERS]WIP: Covering + unique indexes.

On Thu, Feb 11, 2016 at 8:46 AM, Anastasia Lubennikova wrote: > 02.02.2016 15:50, Anastasia Lubennikova: > > As promised, here's the new version of the patch "including_columns_4.0". > I fixed all issues except some points mentioned below. Thanks for the update patch. I get a compiler warning:

Re: [HACKERS]WIP: Covering + unique indexes.

02.02.2016 15:50, Anastasia Lubennikova: 31.01.2016 11:04, David Rowley: On 27 January 2016 at 03:35, Anastasia Lubennikova wrote: including_columns_3.0 is the latest version of patch. And changes regarding the previous version are attached in a separate patch. Just to ease the review and de

Re: [HACKERS]WIP: Covering + unique indexes.

Anastasia Lubennikova wrote: > I just write here to say that I do not disappear and I do remember about the > issue. > But I'm very very busy this week. I'll send an updated patch next week as > soon as possible. That's great to know, thanks. I moved your patch to the next commitfest. Please do

Re: [HACKERS]WIP: Covering + unique indexes.

31.01.2016 11:04, David Rowley: On 27 January 2016 at 03:35, Anastasia Lubennikova wrote: including_columns_3.0 is the latest version of patch. And changes regarding the previous version are attached in a separate patch. Just to ease the review and debug. Hi, I've made another pass over the p

Re: [HACKERS]WIP: Covering + unique indexes.

On 27 January 2016 at 03:35, Anastasia Lubennikova wrote: > including_columns_3.0 is the latest version of patch. > And changes regarding the previous version are attached in a separate patch. > Just to ease the review and debug. Hi, I've made another pass over the patch. There's still a couple

Re: [HACKERS]WIP: Covering + unique indexes.

25.01.2016 03:32, Jeff Janes: On Fri, Jan 22, 2016 at 7:19 AM, Anastasia Lubennikova wrote: Done. I hope that my patch is close to the commit too. Thanks for the update. I've run into this problem: create table foobar (x text, w text); create unique index foobar_pkey on foobar (x) including

Re: [HACKERS]WIP: Covering + unique indexes.

On Fri, Jan 22, 2016 at 7:19 AM, Anastasia Lubennikova wrote: > > Done. I hope that my patch is close to the commit too. > Thanks for the update. I've run into this problem: create table foobar (x text, w text); create unique index foobar_pkey on foobar (x) including (w); alter table foobar add

Re: [HACKERS]WIP: Covering + unique indexes.

22.01.2016 01:47, David Rowley: On 20 January 2016 at 06:08, Anastasia Lubennikova wrote: 18.01.2016 01:02, David Rowley пишет: On 14 January 2016 at 08:24, David Rowley wrote: I will try to review the omit_opclass_4.0.patch soon. Hi, as promised, here's my review of the omit_opclass_4.0

Re: [HACKERS]WIP: Covering + unique indexes.

On 20 January 2016 at 06:08, Anastasia Lubennikova wrote: > > > > 18.01.2016 01:02, David Rowley пишет: > > On 14 January 2016 at 08:24, David Rowley > wrote: >> >> I will try to review the omit_opclass_4.0.patch soon. > > > Hi, as promised, here's my review of the omit_opclass_4.0.patch patch.

Re: [HACKERS]WIP: Covering + unique indexes.

On Tue, Jan 19, 2016 at 9:08 AM, Anastasia Lubennikova wrote: > > > 18.01.2016 01:02, David Rowley пишет: > > On 14 January 2016 at 08:24, David Rowley > wrote: >> >> I will try to review the omit_opclass_4.0.patch soon. > > > Hi, as promised, here's my review of the omit_opclass_4.0.patch patch.

Re: [HACKERS]WIP: Covering + unique indexes.

12.01.2016 20:47, Jeff Janes: It looks like the "covering" patch, with or without the "omit_opclass" patch, does not support expressions as included columns: create table foobar (x text, y xml); create index on foobar (x) including (md5(x)); ERROR: unrecognized node type: 904 create index on

Re: [HACKERS]WIP: Covering + unique indexes.

18.01.2016 01:02, David Rowley пишет: On 14 January 2016 at 08:24, David Rowley mailto:david.row...@2ndquadrant.com>> wrote: I will try to review the omit_opclass_4.0.patch soon. Hi, as promised, here's my review of the omit_opclass_4.0.patch patch. Thank you again. All mentioned poi

Re: [HACKERS]WIP: Covering + unique indexes.

On 14 January 2016 at 08:24, David Rowley wrote: > I will try to review the omit_opclass_4.0.patch soon. > Hi, as promised, here's my review of the omit_opclass_4.0.patch patch. The following comment needs to be updated: * indexkeys[], indexcollations[], opfamily[], and opcintype[] * each ha

Re: [HACKERS]WIP: Covering + unique indexes.

On 14 January 2016 at 02:58, Anastasia Lubennikova < a.lubennik...@postgrespro.ru> wrote: > 13.01.2016 04:27, David Rowley: > >> I've also done some testing: >> >> create table ab (a int, b int); >> insert into ab select a,b from generate_Series(1,10) a(a), >> generate_series(1,1) b(b); >> set

Re: [HACKERS]WIP: Covering + unique indexes.

13.01.2016 04:27, David Rowley: I've also done some testing: create table ab (a int, b int); insert into ab select a,b from generate_Series(1,10) a(a), generate_series(1,1) b(b); set enable_bitmapscan=off; set enable_indexscan=off; select * from ab where a = 1 and b=1; a | b ---+--- 1 |

Re: [HACKERS]WIP: Covering + unique indexes.

13.01.2016 04:47, David Rowley : On 13 January 2016 at 06:47, Jeff Janes > wrote: Why is omit_opclass a separate patch? If the included columns now never participate in the index ordering, shouldn't it be an inherent property of the main patch that yo

Re: [HACKERS]WIP: Covering + unique indexes.

On 13 January 2016 at 06:47, Jeff Janes wrote: > > Why is omit_opclass a separate patch? If the included columns now > never participate in the index ordering, shouldn't it be an inherent > property of the main patch that you can "cover" things without btree > opclasses? > > I also wondered this

Re: [HACKERS]WIP: Covering + unique indexes.

On 13 January 2016 at 05:59, Anastasia Lubennikova < a.lubennik...@postgrespro.ru> wrote: > 08.01.2016 00:12, David Rowley: > > On 7 January 2016 at 06:36, Jeff Janes wrote: > >> On Tue, Jan 5, 2016 at 11:55 PM, David Rowley >> wrote: >> > create table ab (a int,b int); >> > insert into ab selec

Re: [HACKERS]WIP: Covering + unique indexes.

On Tue, Jan 12, 2016 at 8:59 AM, Anastasia Lubennikova wrote: > 08.01.2016 00:12, David Rowley: > > On 7 January 2016 at 06:36, Jeff Janes wrote: >> > But now I see the reason to create non-unique index with included columns - > lack of suitable opclass on column "b". > It's impossible to add it

Re: [HACKERS]WIP: Covering + unique indexes.

08.01.2016 00:12, David Rowley: On 7 January 2016 at 06:36, Jeff Janes > wrote: On Tue, Jan 5, 2016 at 11:55 PM, David Rowley mailto:david.row...@2ndquadrant.com>> wrote: > create table ab (a int,b int); > insert into ab select x,y from generate_serie

Re: [HACKERS]WIP: Covering + unique indexes.

04.01.2016 11:49, David Rowley: On 2 December 2015 at 01:53, Anastasia Lubennikova mailto:a.lubennik...@postgrespro.ru>> wrote: Finally, completed patch "covering_unique_3.0.patch" is here. It includes the functionality discussed above in the thread, regression tests and docs upda

Re: [HACKERS]WIP: Covering + unique indexes.

On 7 January 2016 at 06:36, Jeff Janes wrote: > On Tue, Jan 5, 2016 at 11:55 PM, David Rowley > wrote: > > create table ab (a int,b int); > > insert into ab select x,y from generate_series(1,20) x(x), > > generate_series(10,1,-1) y(y); > > create index on ab (a) including (b); > > explain select

Re: [HACKERS]WIP: Covering + unique indexes.

On Tue, Jan 5, 2016 at 11:55 PM, David Rowley wrote: > On 4 January 2016 at 21:49, David Rowley > wrote: >> >> I've not tested the patch yet. I will send another email soon with the >> results of that. > > > Hi, > > As promised I've done some testing on this, and I've found something which > is n

Re: [HACKERS]WIP: Covering + unique indexes.

On 4 January 2016 at 21:49, David Rowley wrote: > I've not tested the patch yet. I will send another email soon with the > results of that. > Hi, As promised I've done some testing on this, and I've found something which is not quite right: create table ab (a int,b int); insert into ab select

Re: [HACKERS]WIP: Covering + unique indexes.

On 2 December 2015 at 01:53, Anastasia Lubennikova < a.lubennik...@postgrespro.ru> wrote: > Finally, completed patch "covering_unique_3.0.patch" is here. > It includes the functionality discussed above in the thread, regression > tests and docs update. > I think it's quite ready for review. > Hi

  1   2   >