Re: WIP: Covering + unique indexes.

From: Anastasia Lubennikova <a(dot)lubennikova(at)postgrespro(dot)ru>
To: Andres Freund <andres(at)anarazel(dot)de>
Cc: Teodor Sigaev <teodor(at)sigaev(dot)ru>, pgsql-hackers(at)postgresql(dot)org, Anastasia Lubennikova <lubennikovaav(at)gmail(dot)com>, Peter Geoghegan <pg(at)heroku(dot)com>, David Steele <david(at)pgmasters(dot)net>, Peter Eisentraut <peter(dot)eisentraut(at)2ndquadrant(dot)com>, Aleksander Alekseev <a(dot)alekseev(at)postgrespro(dot)ru>
Subject: Re: WIP: Covering + unique indexes.
Date: 2017-03-31 18:04:46
Message-ID: bb4b24dd-eb80-97c8-5cb1-63dca80c8ec5@postgrespro.ru
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

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 strange. I have to set
>> tupdesc->nattrs to support compatibility with index_form_tuple().
>> I didn't want to add neither a new field to tupledesc nor a new
>> parameter to index_form_tuple(), because they are used widely.
>>
>>
>> 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 tupledesc to
>> pass it to index_form_tuple.
> That seems like it'd actually be a noticeable increase in memory
> allocator overhead. I think we should just add (as just proposed in
> separate thread), a _extended version of it that allows to specify the
> number of columns.

The function is called not that often. Only once per page split for
indexes with included columns.
Doesn't look like dramatic overhead. So I decided that a wrapper
function would be more appropriate than refactoring of all
index_form_tuple() calls.
But index_form_tuple_extended() looks like a better solution.

--
Anastasia Lubennikova
Postgres Professional: http://www.postgrespro.com
The Russian Postgres Company

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Masahiko Sawada 2017-03-31 18:05:07 Re: GUC for cleanup indexes threshold.
Previous Message Fabien COELHO 2017-03-31 18:04:04 merge psql ef/ev sf/sv handling functions