Re: [HACKERS] Surjective functional indexes - Mailing list pgsql-hackers

From Konstantin Knizhnik
Subject Re: [HACKERS] Surjective functional indexes
Date
Msg-id 6d781672-d9fd-c809-c835-635c2b9c8f48@postgrespro.ru
Whole thread Raw
In response to Re: [HACKERS] Surjective functional indexes  (Simon Riggs <simon@2ndquadrant.com>)
Responses Re: [HACKERS] Surjective functional indexes
Re: [HACKERS] Surjective functional indexes
List pgsql-hackers

On 01.02.2018 03:10, Simon Riggs wrote:
> On 10 January 2018 at 09:54, Konstantin Knizhnik
> <k.knizhnik@postgrespro.ru> wrote:
>
>> (new version attached)
> Why this comment?
>
> Current implementation of projection optimization has to calculate
> index expression twice
> in case of hit (value of index expression is not changed) and three
> times if values are different.
>
> Old + New for check = 2
> plus calculate again in index = 3
> ?
>
Sorry, I do not completely understand your question.
You do not agree with this statement or you think that this comment is 
irrelevant in this place?
Or you just want to understand why index expression is calculated 2/3 
times? If so, then you have answered this question yourself:
> Old + New for check = 2
> plus calculate again in index = 3

Yes, we have to calculate the value of index expression for original and 
updated version of the record. If them are equal, then it is all we have 
to do with this index: hot update is applicable.
In this case we calculate index expression twice.
But if them are not equal, then hot update is not applicable and we have 
to update index. In this case expression will be calculated one more 
time. So totally three times.
This is why, if calculation of index expression is very expensive, then 
effect of this optimization may be negative even if value of index 
expression is not changed.


-- 
Konstantin Knizhnik
Postgres Professional: http://www.postgrespro.com
The Russian Postgres Company



pgsql-hackers by date:

Previous
From: Tomas Vondra
Date:
Subject: Re: STATISTICS retained in CREATE TABLE ... LIKE (INCLUDING ALL)?
Next
From: Amit Langote
Date:
Subject: Re: constraint exclusion and nulls in IN (..) clause