Re: WIP: Covering + unique indexes.

From: Anastasia Lubennikova <a(dot)lubennikova(at)postgrespro(dot)ru>
To: Peter Geoghegan <pg(at)heroku(dot)com>
Cc: David Steele <david(at)pgmasters(dot)net>, Michael Paquier <michael(dot)paquier(at)gmail(dot)com>, PostgreSQL mailing lists <pgsql-hackers(at)postgresql(dot)org>, David Rowley <david(dot)rowley(at)2ndquadrant(dot)com>
Subject: Re: WIP: Covering + unique indexes.
Date: 2016-04-06 14:49:09
Views: Raw Message | Whole Thread | Download mbox | Resend email
Lists: pgsql-hackers

06.04.2016 16:15, Anastasia Lubennikova :
> 06.04.2016 03:05, Peter Geoghegan:
>> * There is some stray whitespace within RelationGetIndexAttrBitmap().
>> I think you should have updated it with code, though. I don't think
>> it's necessary for HOT updates to work, but I think it could be
>> necessary so that we don't need to get a row lock that blocks
>> non-conflict foreign key locking (see heap_update() callers). I think
>> you need to be careful for non-key columns within the loop in
>> RelationGetIndexAttrBitmap(), basically, because it seems to still go
>> through all columns. UPSERT also must call this code, FWIW.
>> * I think that a similar omission is also made for the replica
>> identity stuff in RelationGetIndexAttrBitmap(). Some thought is needed
>> on how this patch interacts with logical decoding, I guess.
> Good point. Indexes are everywhere in the code.
> I missed that RelationGetIndexAttrBitmap() is used not only for REINDEX.
> I'll discuss it with Theodor and send an updated patch tomorrow.

As promised, updated patch is in attachments.
But, I'm not an expert in this area, so it needs a 'critical look'.

Anastasia Lubennikova
Postgres Professional:
The Russian Postgres Company

Attachment Content-Type Size
including_columns_9.1.patch text/x-patch 133.8 KB

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Magnus Hagander 2016-04-06 15:48:02 Re: [CommitFest App] Feature request -- review e-mail additions
Previous Message Fujii Masao 2016-04-06 14:41:58 Re: Support for N synchronous standby servers - take 2