On 2018-04-07 14:27, Alexander Korotkov wrote:
On Sat, Apr 7, 2018 at 2:57 PM, Erik Rijkers <e...@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
