Re: WIP: Covering + unique indexes. (the good and the bad)
От | Erik Rijkers |
---|---|
Тема | Re: WIP: Covering + unique indexes. (the good and the bad) |
Дата | |
Msg-id | 51ec70c2fac0ee4adfeb0650028395b2@xs4all.nl обсуждение исходный текст |
Ответ на | Re: WIP: Covering + unique indexes. (the good and the bad) (Alexander Korotkov <a.korotkov@postgrespro.ru>) |
Список | pgsql-hackers |
On 2018-04-07 14:27, Alexander Korotkov wrote: > On Sat, Apr 7, 2018 at 2:57 PM, Erik Rijkers <er@xs4all.nl> 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 don't >> think >> it has been mentioned (but I may have missed something in this thread >> that's now been running for 1.5 year, not to mention the tangential >> btree-thread(s)). >> >> I attach my test-program, which compares master (this morning) with >> covered_indexes (warning: it takes a while to generate the used >> tables). >> >> The test tables are created as: >> create table $t (c1 int, c2 int, c3 int, c4 int); >> insert into $t (select x, 2*x, 3*x, 4 from generate_series(1, >> $rowcount) >> as x); >> 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); >> > > Do I understand correctly that you compare unique index on (c1, c2) > with > master to unqiue index on (c1, c2) include (c3, c4) with patched > version? > If so then I think it's wrong to say about down-side/slow-down of this > patch based on this comparison. > Patch *does not* cause slowdown in this case. Patch provides user a > *new > option* which has its advantages and disadvantages. And what you > compare > is advantages and disadvantages of this option, not slow-down of the > patch. > In the case you compare *the same* index on master and patched version, > then it's possible to say about slow-down of the patch. OK, I take your point -- you are right. Although my measurement was (I think) correct, my comparison was not (as Teodor wrote, not quite 'fair'). Sorry, I should have better thought that message through. The somewhat longer time is indeed just a disadvantage of this new option, to be balanced against the advantages that are pretty clear too. Erik Rijkers
В списке pgsql-hackers по дате отправления: