Re: Index only scans - Mailing list pgsql-hackers

From Sharmila Jothirajah
Subject Re: Index only scans
Date
Msg-id 673107EFBDBE53419C100C0A56E118CA0EF2372532@rg-exchange.RII.local
Whole thread Raw
In response to Index only scans  (Shrish Purohit <shrish_purohit@persistent.co.in>)
List pgsql-hackers
Hi Shrish,
I saw the excel that you sent to Heikki. Here are my comments.

1. Don't worry about comparing the results with Oracle. Just take pg-normal and pg-enhanced. That's what the community
caresabout. Later we can also add Oracle's performance.  
2. In the excel sheet you have 'simple queries' and 'simple queries repeated'...you have to compile them together.
3. Also for pg-normal, the queries are run with seq scan and not forcing 'index scan' . If you compare that run with
pg-enhancedit will definitely look bad. You have to compare pg-enh with pg-normal's indexscan (and also seq scan). That
willgive a complete picture. 

These performance numbers that we sent them is very important. Make sure the excel is formatted and is very clear
beforeyour sent the numbers. Its hard to get the community to respond if our reports are not clear 

Thanks
Sharmila



-----Original Message-----
From: Shrish Purohit [mailto:shrish_purohit@persistent.co.in]
Sent: Monday, May 31, 2010 11:09 AM
To: Heikki Linnakangas
Cc: pgsql-hackers@postgresql.org; Sharmila Jothirajah; Mahesh Nalkande; Arvind Hulgeri; Sameer Pendharkar
Subject: Index only scans

Hi Heikki, Pgsql-Hackers,

Sometime back you have started with "Separate Heap Fetch from Index Scan" which was planned to support partial index
onlyscans. Are you still working on it or do you know someone still working on it?  

We did some development with Gokul's Index Only Patch and have got good performance numbers which are as follows:

Test table constitutes 0.5 billion records with thick index on (id,aid) on three machines {pg_normal , pg_enhanced(
PGSQLwith thick index feature ), Oracle} each having 16 Gb Ram. Disk I/O obtained using sar.  

testdb=# \d test          Table "public.test" Column   |       Type       | Modifiers
-----------+------------------+-----------id        | integer          |startdate | date             |enddate   | date
          |charge    | double precision |firstname | text             |lastname  | text             |aid       | double
precision|bid       | double precision | 
Indexes:   "taid" THICK btree (id, aid) CLUSTER

Index size
On oracle         15.20 Gb
On Pg-normal     14.73 Gb
Pg_enhanced     23.17 Gb (16bytes*0.5billion = ~7.6 GB)

PFA excel sheet for details. In general we saw fair amount of performance improvement, but one thing that surprises us
isthat after around 20% tuples updated we found oracle taking more time.  

Regards,
Shrish Purohit |Senior Software Engineer|Persistent Systems shrish_purohit@persistent.co.in
|Cell:+91-9850-959-940|Tel:+91(20)302-34493
Innovation in software product design, development and delivery- www.persistentsys.com

DISCLAIMER
==========
This e-mail may contain privileged and confidential information which is the property of Persistent Systems Ltd. It is
intendedonly for the use of the individual or entity to which it is addressed. If you are not the intended recipient,
youare not authorized to read, retain, copy, print, distribute or use this message. If you have received this
communicationin error, please notify the sender and delete all copies of this message. Persistent Systems Ltd. does not
acceptany liability for virus infected mails. 


pgsql-hackers by date:

Previous
From: Greg Stark
Date:
Subject: Re: functional call named notation clashes with SQL feature
Next
From: "Marc G. Fournier"
Date:
Subject: Re: PG 9.0 release timetable