Re: [HACKERS] Surjective functional indexes

Поиск
Список
Период
Сортировка
От Konstantin Knizhnik
Тема Re: [HACKERS] Surjective functional indexes
Дата
Msg-id 6d781672-d9fd-c809-c835-635c2b9c8f48@postgrespro.ru
обсуждение исходный текст
Ответ на Re: [HACKERS] Surjective functional indexes  (Simon Riggs <simon@2ndquadrant.com>)
Ответы Re: [HACKERS] Surjective functional indexes  (Simon Riggs <simon@2ndquadrant.com>)
Re: [HACKERS] Surjective functional indexes  ("David G. Johnston" <david.g.johnston@gmail.com>)
Список 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 по дате отправления:

Предыдущее
От: Tomas Vondra
Дата:
Сообщение: Re: STATISTICS retained in CREATE TABLE ... LIKE (INCLUDING ALL)?
Следующее
От: Amit Langote
Дата:
Сообщение: Re: constraint exclusion and nulls in IN (..) clause