On 17 November 2014 16:05, Simon Riggs Wrote:
I confirm 5% improvement in both short and long index scans, on the least
beneficial datatype. Looks likely to be a very positive win overall.
Thanks a lot for testing and confirmation.
The language used in the comments is not clear enough.
On 30 October 2014 08:43, Haribabu Kommi kommi.harib...@gmail.com wrote:
I marked the patch as ready for committer.
This looks very interesting.
The value of the patch seems to come from skipping costly checks. Your
performance test has a leading VARCHAR column, so in that specific
case
On Mon, Oct 27, 2014 at 10:38 PM, Rajeev rastogi
rajeev.rast...@huawei.com wrote:
On 26 October 2014 10:42, Haribabu Kommi wrote:
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
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
On Tue, Sep 23, 2014 at 10:38 PM, Rajeev rastogi
rajeev.rast...@huawei.com wrote:
On 22 September 2014 19:17, Heikki Linnakangas wrote:
On 09/22/2014 04:45 PM, Tom Lane wrote:
Heikki Linnakangas hlinnakan...@vmware.com writes:
On 09/22/2014 07:47 AM, Rajeev rastogi wrote:
So my proposal
On 22 September 2014 14:46, Heikki Linnakangas hlinnakan...@vmware.com wrote:
On 09/22/2014 04:45 PM, Tom Lane wrote:
Heikki Linnakangas hlinnakan...@vmware.com writes:
On 09/22/2014 07:47 AM, Rajeev rastogi wrote:
So my proposal is to skip the condition check on the first scan key
On 22 September 2014 18:51, Stephen Frost Wrote:
* Rajeev rastogi (rajeev.rast...@huawei.com) wrote:
Thanks, I shall start to prepare a patch for this optimization and share in 1
or 2 days.
This sounded interesting to me also- please be sure to put it on the open
commitfest once you have
On 22 September 2014 19:17, Heikki Linnakangas wrote:
On 09/22/2014 04:45 PM, Tom Lane wrote:
Heikki Linnakangas hlinnakan...@vmware.com writes:
On 09/22/2014 07:47 AM, Rajeev rastogi wrote:
So my proposal is to skip the condition check on the first scan key
condition for every tuple.
On 09/22/2014 07:47 AM, Rajeev rastogi wrote:
I have observed a scope of considerable performance improvement in-case of
index by a very minor code change.
Consider the below schema:
create table tbl2(id1 int, id2 varchar(10), id3 int);
create index idx2 on tbl2(id2, id3);
Query as:
On 22 September 2014 12:35, Heikki Linnakangas:
I have observed a scope of considerable performance improvement in-
case of index by a very minor code change.
Consider the below schema:
create table tbl2(id1 int, id2 varchar(10), id3 int); create index
idx2 on tbl2(id2, id3);
Query
* Rajeev rastogi (rajeev.rast...@huawei.com) wrote:
Thanks, I shall start to prepare a patch for this optimization and share in 1
or 2 days.
This sounded interesting to me also- please be sure to put it on the
open commitfest once you have posted the patch.
Thanks!
Heikki Linnakangas hlinnakan...@vmware.com writes:
On 09/22/2014 07:47 AM, Rajeev rastogi wrote:
So my proposal is to skip the condition check on the first scan key
condition for every tuple.
The same happens in a single-column case. If you have a query like
SELECT * FROM tbl2 where id2
On 09/22/2014 04:45 PM, Tom Lane wrote:
Heikki Linnakangas hlinnakan...@vmware.com writes:
On 09/22/2014 07:47 AM, Rajeev rastogi wrote:
So my proposal is to skip the condition check on the first scan key condition
for every tuple.
The same happens in a single-column case. If you have a
I have observed a scope of considerable performance improvement in-case of
index by a very minor code change.
Consider the below schema:
create table tbl2(id1 int, id2 varchar(10), id3 int);
create index idx2 on tbl2(id2, id3);
Query as:
select count(*) from tbl2 where id2'a'
14 matches
Mail list logo
