Re: WIP: Covering + unique indexes. (the good and the bad)

Erik Rijkers <er@xs4all.nl>

From: Erik Rijkers <er@xs4all.nl>
To: Alexander Korotkov <a.korotkov@postgrespro.ru>
Cc: Peter Geoghegan <pg@bowt.ie>, Teodor Sigaev <teodor@sigaev.ru>, Anastasia Lubennikova <a.lubennikova@postgrespro.ru>, PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>, Alexander Kuzmenkov <a.kuzmenkov@postgrespro.ru>
Date: 2018-04-07T12:56:13Z
Lists: 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


Commits

  1. Adjust INCLUDE index truncation comments and code.

  2. Add commentary explaining why MaxIndexTuplesPerPage calculation is safe.

  3. Indexes with INCLUDE columns and their support in B-tree

  4. Add amcheck verification of heap relations belonging to btree indexes.

  5. Doc: move info for btree opclass implementors into main documentation.

  6. Doc: mention that you can't PREPARE TRANSACTION after NOTIFY.

  7. Remove dedicated B-tree root-split record types.

  8. Restructure index access method API to hide most of it at the C level.

  9. Split _bt_insertonpg to two functions.

  10. Major overhaul of btree index code. Eliminate special BTP_CHAIN logic for