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
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] |