From: | Erik Rijkers <er(at)xs4all(dot)nl> |
---|---|
To: | Alexander Korotkov <a(dot)korotkov(at)postgrespro(dot)ru> |
Cc: | Peter Geoghegan <pg(at)bowt(dot)ie>, Teodor Sigaev <teodor(at)sigaev(dot)ru>, Anastasia Lubennikova <a(dot)lubennikova(at)postgrespro(dot)ru>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>, Alexander Kuzmenkov <a(dot)kuzmenkov(at)postgrespro(dot)ru> |
Subject: | Re: WIP: Covering + unique indexes. (the good and the bad) |
Date: | 2018-04-07 12:56:13 |
Message-ID: | 51ec70c2fac0ee4adfeb0650028395b2@xs4all.nl |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On 2018-04-07 14:27, Alexander Korotkov wrote:
> On Sat, Apr 7, 2018 at 2:57 PM, Erik Rijkers <er(at)xs4all(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | Magnus Hagander | 2018-04-07 12:57:53 | Re: Bring atomic flag fallback up to snuff |
Previous Message | Teodor Sigaev | 2018-04-07 12:48:06 | Re: WIP: Covering + unique indexes. |