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

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

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 >>

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

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.

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

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

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

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

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

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

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 >

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

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

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 @@

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

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

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

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

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

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

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 >>

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

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

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

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

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

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

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.

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

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

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

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

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

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

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

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,

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 >>

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

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

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); -

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 =

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

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 >>

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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.

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

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:

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

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:

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

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/

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

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

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

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

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.

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,

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

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

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

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)

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

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

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

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

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[],

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

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.

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); >>

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

04.01.2016 11:49, David Rowley: On 2 December 2015 at 01:53, Anastasia Lubennikova > wrote: Finally, completed patch "covering_unique_3.0.patch" is here. It includes the functionality discussed above in the thread,

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

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: >> >

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? >

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 > wrote: > create table ab (a

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); > >

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

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

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

On Tue, Dec 1, 2015 at 4:53 AM, Anastasia Lubennikova 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.

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

On Sat, Dec 26, 2015 at 5:58 PM, Jeff Janes wrote: > > And the dblink contrib module fails its make check. Ignore the dblink complaint. It seems to have been some wonky build issue that is not reproducible. -- Sent via pgsql-hackers mailing list

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

03.12.2015 04:03, Robert Haas пишет: On Tue, Dec 1, 2015 at 7:53 AM, Anastasia Lubennikova wrote: If we don't need c4 as an index scankey, we don't need any btree opclass on it. But we still want to have it in covering index for queries like SELECT c4 FROM tbl

  1   2   >