Re: Index scan optimization

From: Rajeev rastogi <rajeev(dot)rastogi(at)huawei(dot)com>
To: Haribabu Kommi <kommi(dot)haribabu(at)gmail(dot)com>
Cc: Heikki Linnakangas <hlinnakangas(at)vmware(dot)com>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, PostgreSQL mailing lists <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Index scan optimization
Date: 2014-10-27 11:38:10
Message-ID: BF2827DCCE55594C8D7A8F7FFD3AB77158E5A8BD@SZXEML508-MBX.china.huawei.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On 26 October 2014 10:42, Haribabu Kommi wrote:

> Hi,
>
> I reviewed index scan optimization patch, the following are the
> observations.
>
> - Patch applies cleanly.
> - Compiles without warnings
> - All regress tests are passed.
>
> There is a good performance gain with the patch in almost all scenarios.

Thanks for reviewing.

> I have a question regarding setting of key flags matched. Only the
> first key was set as matched even if we have multiple index conditions.
> Is there any reason behind that?

Actually the keysCount can be more than one only if the key strategy is BTEqualStrategyNumber (i.e. = condition)
But our optimization is only for the '>' or '>=' condition only. So adding code to set flag for all keys is of no use.

Let me know if I am missing anything here?

> If any volatile function is present in the index condition, the index
> scan itself is not choosen, Is there any need of handling the same
> similar to NULLS?

Do you mean to say that whether we should add any special handling for volatile function?
If yes then as you said since index scan itself is not selected for such functions, then
I feel We don’t need to add anything for that.
Any opinion?

Thanks and Regards,
Kumar Rajeev Rastogi

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Andres Freund 2014-10-27 11:44:21 Re: On partitioning
Previous Message Thom Brown 2014-10-27 11:37:17 Re: KNN searches support for SP-GiST [GSOC'14]